Date: Wed, 29 May 2024 11:01:43 -0500
From: Tom Zanussi <tom.zanussi@...ux.intel.com>
To: Masami Hiramatsu <mhiramat@...nel.org>
Cc: Steven Rostedt <rostedt@...dmis.org>, LKML
 <linux-kernel@...r.kernel.org>,  Linux Trace Kernel
 <linux-trace-kernel@...r.kernel.org>
Subject: Re: [PATCH 0/3] tracing: Fix some selftest issues

Hi Masami,

On Wed, 2024-05-29 at 08:38 +0900, Masami Hiramatsu wrote:
> 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?
> 

Yeah, this module was meant as a sample module showing how to create
and generate synthetic events in-kernel.

So the interested user insmods the module, looks at the trace stream
and sees, ok the events are there as expected, so it does work, great,
let's remove the module to get rid of them and go write our own.

Having both the creation and cleanup in module_init() wouldn't allow
the user the opportunity to do that i.e. verify the results by reading
the trace file.

Tom 

> 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>
> 
> 

Powered by blists - more mailing lists