rcu.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Paul E. McKenney" <paulmck@kernel.org>
To: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: rcu@vger.kernel.org,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Kernel Team <kernel-team@fb.com>, Ingo Molnar <mingo@kernel.org>,
	Lai Jiangshan <jiangshanlai@gmail.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
	Josh Triplett <josh@joshtriplett.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Peter Zijlstra <peterz@infradead.org>,
	Steven Rostedt <rostedt@goodmis.org>,
	David Howells <dhowells@redhat.com>,
	Eric Dumazet <edumazet@google.com>,
	Frederic Weisbecker <fweisbec@gmail.com>,
	Oleg Nesterov <oleg@redhat.com>,
	Joel Fernandes <joel@joelfernandes.org>
Subject: Re: [PATCH tip/core/rcu 3/4] rcutorture: Make grace-period kthread report match RCU flavor being tested
Date: Tue, 15 Dec 2020 10:24:19 -0800	[thread overview]
Message-ID: <20201215182419.GD2657@paulmck-ThinkPad-P72> (raw)
In-Reply-To: <CAMuHMdXjUxfp0h=TiwNoZJUHrSD4sDwYEbuqNR4rcWSRFCjUtw@mail.gmail.com>

On Tue, Dec 15, 2020 at 09:40:26AM +0100, Geert Uytterhoeven wrote:
> Hi Paul,

Hello, Geert, and thank you for looking this over!

> On Fri, Nov 6, 2020 at 12:40 AM <paulmck@kernel.org> wrote:
> >
> > From: "Paul E. McKenney" <paulmck@kernel.org>
> >
> > At the end of the test and after rcu_torture_writer() stalls, rcutorture
> > invokes show_rcu_gp_kthreads() in order to dump out information on the
> > RCU grace-period kthread.  This makes a lot of sense when testing vanilla
> > RCU, but not so much for the other flavors.  This commit therefore allows
> > per-flavor kthread-dump functions to be specified.
> >
> > [ paulmck: Apply feedback from kernel test robot <lkp@intel.com>. ]
> > Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
> 
> Thanks for your patch, which is now commit 27c0f1448389baf7
> ("rcutorture: Make grace-period kthread report match RCU flavor being
> tested").
> 
> > --- a/kernel/rcu/rcu.h
> > +++ b/kernel/rcu/rcu.h
> > @@ -533,4 +533,20 @@ static inline bool rcu_is_nocb_cpu(int cpu) { return false; }
> >  static inline void rcu_bind_current_to_nocb(void) { }
> >  #endif
> >
> > +#if !defined(CONFIG_TINY_RCU) && defined(CONFIG_TASKS_RCU)
> > +void show_rcu_tasks_classic_gp_kthread(void);
> > +#else
> > +static inline void show_rcu_tasks_classic_gp_kthread(void) {}
> > +#endif
> > +#if !defined(CONFIG_TINY_RCU) && defined(CONFIG_TASKS_RUDE_RCU)
> > +void show_rcu_tasks_rude_gp_kthread(void);
> > +#else
> > +static inline void show_rcu_tasks_rude_gp_kthread(void) {}
> > +#endif
> 
> The #ifdef expression does not match the one for the implementation
> below.

That does sound like something I would do...

The definition of show_rcu_tasks_rude_gp_kthread() must be provided
elsewhere if !TINY_RCU && TASKS_RUDE_RCU, correct?

> > --- a/kernel/rcu/rcutorture.c
> > +++ b/kernel/rcu/rcutorture.c
> 
> > @@ -762,6 +765,7 @@ static struct rcu_torture_ops tasks_rude_ops = {
> >         .exp_sync       = synchronize_rcu_tasks_rude,
> >         .call           = call_rcu_tasks_rude,
> >         .cb_barrier     = rcu_barrier_tasks_rude,
> > +       .gp_kthread_dbg = show_rcu_tasks_rude_gp_kthread,
> 
> Perhaps you just want to have a NULL pointer for the dummy case, instead
> of instantiating a dummy static inline function and taking its address?

You mean something like this in kernel/rcu/rcu.h?

#if !defined(CONFIG_TINY_RCU) && defined(CONFIG_TASKS_RUDE_RCU)
void show_rcu_tasks_rude_gp_kthread(void);
#else
#define show_rcu_tasks_rude_gp_kthread NULL
#endif

This does looks better to me, and at first glance would work.

This patch is already in mainline, but if the second approach above
works, I would welcome a patch making that change.

> >         .fqs            = NULL,
> >         .stats          = NULL,
> >         .irq_capable    = 1,
> 
> 
> > --- a/kernel/rcu/tasks.h
> > +++ b/kernel/rcu/tasks.h
> 
> > @@ -696,16 +696,14 @@ static int __init rcu_spawn_tasks_rude_kthread(void)
> >  }
> >  core_initcall(rcu_spawn_tasks_rude_kthread);
> >
> > -#ifndef CONFIG_TINY_RCU
> > -static void show_rcu_tasks_rude_gp_kthread(void)
> > +#if !defined(CONFIG_TINY_RCU)
> 
> Different #ifdef expression.

I don't believe that it is.  The above supplies the !TINY_RCU, and a
prior #ifdef supplies the TASKS_RUDE_RCU.  So what am I missing here?

> > +void show_rcu_tasks_rude_gp_kthread(void)
> 
> Do you really want to define a non-static function...

Yes, because its user is in kernel/rcu/rcutorture.c, which is in
a separate translation unit, so it must be non-static.  The earlier
version instead only called it from this file, but that turned out to
produce confusing output containing information for flavors of RCU that
were not under test.  So this commit exported it to allow rcutorture to
complain about only that RCU flavor being tested.

> >  {
> >         show_rcu_tasks_generic_gp_kthread(&rcu_tasks_rude, "");
> >  }
> > -#endif /* #ifndef CONFIG_TINY_RCU */
> > -
> > -#else /* #ifdef CONFIG_TASKS_RUDE_RCU */
> > -static void show_rcu_tasks_rude_gp_kthread(void) {}
> > -#endif /* #else #ifdef CONFIG_TASKS_RUDE_RCU */
> > +EXPORT_SYMBOL_GPL(show_rcu_tasks_rude_gp_kthread);
> 
> ... and export its symbol, from a header file?
> I know the file is included only once.

Because kernel/rcu/rcutorture.c can be built as a module, it must be
exported.  I agree that it is unusual to export from a .h file, but the
single inclusion is intentional.  There are several other .h files in
kernel/rcu that are also split out to group similar functionality while
still allowing the compiler to inline to its heart's content.

Yes, this is a bit unconventional, but it has been this way for more
than a decade, at least for tree_plugin.h.

Again, please let me know if I am missing something.

							Thanx, Paul

> > +#endif // !defined(CONFIG_TINY_RCU)
> > +#endif /* #ifdef CONFIG_TASKS_RUDE_RCU */
> >
> >  ////////////////////////////////////////////////////////////////////////
> >  //
> 
> Gr{oetje,eeting}s,
> 
>                         Geert
> 
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
> 
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
>                                 -- Linus Torvalds

  reply	other threads:[~2020-12-15 18:25 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-05 23:39 [PATCH tip/core/rcu 0/4] RCU-tasks updates for v5.11 Paul E. McKenney
2020-11-05 23:39 ` [PATCH tip/core/rcu 1/4] rcutorture: Make preemptible TRACE02 enable lockdep paulmck
2020-11-05 23:39 ` [PATCH tip/core/rcu 2/4] rcu-tasks: Convert rcu_tasks_wait_gp() for-loop to while-loop paulmck
2020-11-05 23:39 ` [PATCH tip/core/rcu 3/4] rcutorture: Make grace-period kthread report match RCU flavor being tested paulmck
2020-12-15  8:40   ` Geert Uytterhoeven
2020-12-15 18:24     ` Paul E. McKenney [this message]
2020-12-16  9:31       ` Geert Uytterhoeven
2020-12-16 16:48         ` Paul E. McKenney
2020-12-27 16:49           ` Paul E. McKenney
2020-11-05 23:39 ` [PATCH tip/core/rcu 4/4] rcu-tasks: Make the units of ->init_fract be jiffies paulmck

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=20201215182419.GD2657@paulmck-ThinkPad-P72 \
    --to=paulmck@kernel.org \
    --cc=akpm@linux-foundation.org \
    --cc=dhowells@redhat.com \
    --cc=edumazet@google.com \
    --cc=fweisbec@gmail.com \
    --cc=geert@linux-m68k.org \
    --cc=jiangshanlai@gmail.com \
    --cc=joel@joelfernandes.org \
    --cc=josh@joshtriplett.org \
    --cc=kernel-team@fb.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mathieu.desnoyers@efficios.com \
    --cc=mingo@kernel.org \
    --cc=oleg@redhat.com \
    --cc=peterz@infradead.org \
    --cc=rcu@vger.kernel.org \
    --cc=rostedt@goodmis.org \
    --cc=tglx@linutronix.de \
    /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;
as well as URLs for NNTP newsgroup(s).