mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Masami Hiramatsu (Google) <mhiramat@kernel.org>
To: Tom Zanussi <tom.zanussi@linux.intel.com>
Cc: Steven Rostedt <rostedt@goodmis.org>,
	LKML <linux-kernel@vger.kernel.org>,
	Linux Trace Kernel <linux-trace-kernel@vger.kernel.org>
Subject: Re: [PATCH 0/3] tracing: Fix some selftest issues
Date: Fri, 31 May 2024 11:37:21 +0900	[thread overview]
Message-ID: <20240531113721.c0314e0cdb3beb70c1a6ba7d@kernel.org> (raw)
In-Reply-To: <3a7e679712fb47b6c75af84163b5d3ea252f4da9.camel@linux.intel.com>

On Wed, 29 May 2024 11:01:43 -0500
Tom Zanussi <tom.zanussi@linux.intel.com> wrote:

> 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@kernel.org> wrote:
> > 
> > > On Mon, 27 May 2024 19:29:07 -0400
> > > Steven Rostedt <rostedt@goodmis.org> wrote:
> > > 
> > > > On Sun, 26 May 2024 19:10:57 +0900
> > > > "Masami Hiramatsu (Google)" <mhiramat@kernel.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.

So, in summary, it is designed to be a module. Steve, I think these tests
should be kept as modules. There are many reason to do so.

 - This test is designed to be used as module.
 - This can conflict with other boot time selftest if it is embedded.
 - We can make these tests and boot time selftest mutable exclusive but
   if we make these tests as modules, we can build and run both tests
   safely.
 - Embedding these tests leave new events when the kernel boot, which
   user must be cleaned up by manual.

What would you think?


Thank you,
> 
> 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@kernel.org>
> > 
> > 
> 
> 


-- 
Masami Hiramatsu (Google) <mhiramat@kernel.org>

  reply	other threads:[~2024-05-31  2:37 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-05-26 10:10 Masami Hiramatsu (Google)
2024-05-26 10:11 ` [PATCH 1/3] tracing: Build event generation tests only as modules Masami Hiramatsu (Google)
2024-05-26 10:11 ` [PATCH 2/3] tracing/kprobe: Remove unneeded WARN_ON_ONCE() in selftests Masami Hiramatsu (Google)
2024-05-26 10:11 ` [PATCH 3/3] tracing/kprobe: Remove cleanup code unrelated to selftest Masami Hiramatsu (Google)
2024-05-27 23:29 ` [PATCH 0/3] tracing: Fix some selftest issues Steven Rostedt
2024-05-28 16:46   ` Masami Hiramatsu
2024-05-28 23:38     ` Masami Hiramatsu
2024-05-29 16:01       ` Tom Zanussi
2024-05-31  2:37         ` Masami Hiramatsu [this message]
2024-05-31  7:24           ` Steven Rostedt
2024-05-31 14:20             ` Masami Hiramatsu
2024-06-04 13:57               ` Steven Rostedt
2024-06-04 14:18                 ` Masami Hiramatsu
2024-06-04 14:30                   ` Steven Rostedt
2024-06-10  2:10             ` Masami Hiramatsu
2024-06-10 19:49               ` Steven Rostedt
2024-06-10 21:26 Masami Hiramatsu (Google)

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20240531113721.c0314e0cdb3beb70c1a6ba7d@kernel.org \
    --to=mhiramat@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-trace-kernel@vger.kernel.org \
    --cc=rostedt@goodmis.org \
    --cc=tom.zanussi@linux.intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®