A recent RFC patch set [1] suggests some additional functionality
may be needed around kunit resources. It seems to require
1. support for resources without allocation
2. support for lookup of such resources
3. support for access to resources across multiple kernel threads
The proposed changes here are designed to address these needs.
The idea is we first generalize the API to support adding
resources with static data; then from there we support named
resources. The latter support is needed because if we are
in a different thread context and only have the "struct kunit *"
to work with, we need a way to identify a resource in lookup.
[1] https://lkml.org/lkml/2020/2/26/1286
Changes since v1:
- reformatted longer parameter lists to have one parameter per-line
(Brendan, patch 1)
- fixed phrasing in various comments to clarify allocation of memory
and added comment to kunit resource tests to clarify why
kunit_put_resource() is used there (Brendan, patch 1)
- changed #define to static inline function (Brendan, patch 2)
- simplified kunit_add_named_resource() to use more of existing
code for non-named resource (Brendan, patch 2)
Alan Maguire (2):
kunit: generalize kunit_resource API beyond allocated resources
kunit: add support for named resources
include/kunit/test.h | 159 +++++++++++++++++++++++++++-------
lib/kunit/kunit-test.c | 111 +++++++++++++++++++-----
lib/kunit/string-stream.c | 14 ++-
lib/kunit/test.c | 211 ++++++++++++++++++++++++++++++++--------------
4 files changed, 371 insertions(+), 124 deletions(-)
--
1.8.3.1
Many systems build/test up-to-date kernels with older libcs, and
an older glibc (2.17) lacks the definition of SOL_DCCP in
/usr/include/bits/socket.h (it was added in the 4.6 timeframe).
Adding the definition to the test program avoids a compilation
failure that gets in the way of building tools/testing/selftests/net.
The test itself will work once the definition is added; either
skipping due to DCCP not being configured in the kernel under test
or passing, so there are no other more up-to-date glibc dependencies
here it seems beyond that missing definition.
Fixes: 11fb60d1089f ("selftests: net: reuseport_addr_any: add DCCP")
Signed-off-by: Alan Maguire <alan.maguire(a)oracle.com>
---
tools/testing/selftests/net/reuseport_addr_any.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/tools/testing/selftests/net/reuseport_addr_any.c b/tools/testing/selftests/net/reuseport_addr_any.c
index c623393..b8475cb2 100644
--- a/tools/testing/selftests/net/reuseport_addr_any.c
+++ b/tools/testing/selftests/net/reuseport_addr_any.c
@@ -21,6 +21,10 @@
#include <sys/socket.h>
#include <unistd.h>
+#ifndef SOL_DCCP
+#define SOL_DCCP 269
+#endif
+
static const char *IP4_ADDR = "127.0.0.1";
static const char *IP6_ADDR = "::1";
static const char *IP4_MAPPED6 = "::ffff:127.0.0.1";
--
1.8.3.1
From: "Steven Rostedt (VMware)" <rostedt(a)goodmis.org>
The ftrace selftest "ftrace - test for function traceon/off triggers"
enables all events and reads the trace file. Now that the trace file does
not disable tracing, and will attempt to continually read new data that is
added, the selftest gets stuck reading the trace file. This is because the
data added to the trace file will fill up quicker than the reading of it.
By only enabling scheduling events, the read can keep up with the writes.
Instead of enabling all events, only enable the scheduler events.
Link: http://lkml.kernel.org/r/20200318111345.0516642e@gandalf.local.home
Cc: Shuah Khan <skhan(a)linuxfoundation.org>
Cc: linux-kselftest(a)vger.kernel.org
Acked-by: Masami Hiramatsu <mhiramat(a)kernel.org>
Signed-off-by: Steven Rostedt (VMware) <rostedt(a)goodmis.org>
---
.../selftests/ftrace/test.d/ftrace/func_traceonoff_triggers.tc | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/testing/selftests/ftrace/test.d/ftrace/func_traceonoff_triggers.tc b/tools/testing/selftests/ftrace/test.d/ftrace/func_traceonoff_triggers.tc
index 0c04282d33dd..1947387fe976 100644
--- a/tools/testing/selftests/ftrace/test.d/ftrace/func_traceonoff_triggers.tc
+++ b/tools/testing/selftests/ftrace/test.d/ftrace/func_traceonoff_triggers.tc
@@ -41,7 +41,7 @@ fi
echo '** ENABLE EVENTS'
-echo 1 > events/enable
+echo 1 > events/sched/enable
echo '** ENABLE TRACING'
enable_tracing
--
2.25.1
On Wed, Mar 18, 2020 at 9:13 AM Steven Rostedt <rostedt(a)goodmis.org> wrote:
>
>
> From: "Steven Rostedt (VMware)" <rostedt(a)goodmis.org>
>
> The ftrace selftest "ftrace - test for function traceon/off triggers"
> enables all events and reads the trace file. Now that the trace file does
> not disable tracing, and will attempt to continually read new data that is
> added, the selftest gets stuck reading the trace file. This is because the
> data added to the trace file will fill up quicker than the reading of it.
>
> By only enabling scheduling events, the read can keep up with the writes.
> Instead of enabling all events, only enable the scheduler events.
>
> Signed-off-by: Steven Rostedt (VMware) <rostedt(a)goodmis.org>
> ---
> .../selftests/ftrace/test.d/ftrace/func_traceonoff_triggers.tc | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
+ linux-kselttest and my LF email.
thanks,
-- Shuah