[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20240529083818.b7835de167191d4567405ce6@kernel.org>
Date: Wed, 29 May 2024 08:38:18 +0900
From: Masami Hiramatsu (Google) <mhiramat@...nel.org>
To: Masami Hiramatsu (Google) <mhiramat@...nel.org>, Tom Zanussi
<zanussi@...nel.org>
Cc: Steven Rostedt <rostedt@...dmis.org>, LKML
<linux-kernel@...r.kernel.org>, Linux Trace Kernel
<linux-trace-kernel@...r.kernel.org>, Tom Zanussi <zanussi@...nel.org>
Subject: Re: [PATCH 0/3] tracing: Fix some selftest issues
On Wed, 29 May 2024 01:46:40 +0900
Masami Hiramatsu (Google) <mhiramat@...nel.org> wrote:
> On Mon, 27 May 2024 19:29:07 -0400
> Steven Rostedt <rostedt@...dmis.org> wrote:
>
> > On Sun, 26 May 2024 19:10:57 +0900
> > "Masami Hiramatsu (Google)" <mhiramat@...nel.org> wrote:
> >
> > > Hi,
> > >
> > > Here is a series of some fixes/improvements for the test modules and boot
> > > time selftest of kprobe events. I found a WARNING message with some boot
> > > time selftest configuration, which came from the combination of embedded
> > > kprobe generate API tests module and ftrace boot-time selftest. So the main
> > > problem is that the test module should not be built-in. But I also think
> > > this WARNING message is useless (because there are warning messages already)
> > > and the cleanup code is redundant. This series fixes those issues.
> >
> > Note, when I enable trace tests as builtin instead of modules, I just
> > disable the bootup self tests when it detects this. This helps with
> > doing tests via config options than having to add user space code that
> > loads modules.
> >
> > Could you do something similar?
>
> OK, in that case, I would like to move the test cleanup code in
> module_exit function into the end of module_init function.
> It looks there is no reason to split those into 2 parts.
Wait, I would like to hear Tom's opinion. I found following usage comments
in the code.
* Following that are a few examples using the created events to test
* various ways of tracing a synthetic event.
*
* To test, select CONFIG_SYNTH_EVENT_GEN_TEST and build the module.
* Then:
*
* # insmod kernel/trace/synth_event_gen_test.ko
* # cat /sys/kernel/tracing/trace
*
* You should see several events in the trace buffer -
* "create_synth_test", "empty_synth_test", and several instances of
* "gen_synth_test".
*
* To remove the events, remove the module:
*
* # rmmod synth_event_gen_test
Tom, is that intended behavior ? and are you expected to reuse these
events outside of the module? e.g. load the test module and run some
test script in user space which uses those events?
As far as I can see, those tests are not intended to be embedded in the
kernel because those are expected to be removed.
Thank you,
>
> Thank you,
>
> >
> > -- Steve
> >
> >
> > >
> > > Thank you,
> > >
> > > ---
> > >
> > > Masami Hiramatsu (Google) (3):
> > > tracing: Build event generation tests only as modules
> > > tracing/kprobe: Remove unneeded WARN_ON_ONCE() in selftests
> > > tracing/kprobe: Remove cleanup code unrelated to selftest
> > >
>
>
> --
> Masami Hiramatsu (Google) <mhiramat@...nel.org>
--
Masami Hiramatsu (Google) <mhiramat@...nel.org>
Powered by blists - more mailing lists