[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <b4ac95ce-7cfd-4d31-aa7d-54ef04f4ae24@paulmck-laptop>
Date: Tue, 25 Mar 2025 08:07:59 -0700
From: "Paul E. McKenney" <paulmck@...nel.org>
To: Geert Uytterhoeven <geert@...ux-m68k.org>
Cc: Boqun Feng <boqun.feng@...il.com>, rcu@...r.kernel.org,
Jonathan Corbet <corbet@....net>,
Steven Rostedt <rostedt@...dmis.org>,
Masami Hiramatsu <mhiramat@...nel.org>,
Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
Frederic Weisbecker <frederic@...nel.org>,
Neeraj Upadhyay <neeraj.upadhyay@...nel.org>,
Joel Fernandes <joel@...lfernandes.org>,
Josh Triplett <josh@...htriplett.org>,
Uladzislau Rezki <urezki@...il.com>,
Lai Jiangshan <jiangshanlai@...il.com>,
Zqiang <qiang.zhang1211@...il.com>,
Davidlohr Bueso <dave@...olabs.net>, Shuah Khan <shuah@...nel.org>,
Andrew Morton <akpm@...ux-foundation.org>,
Thomas Huth <thuth@...hat.com>,
"Borislav Petkov (AMD)" <bp@...en8.de>,
Ard Biesheuvel <ardb@...nel.org>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Josh Poimboeuf <jpoimboe@...nel.org>,
Yury Norov <yury.norov@...il.com>,
Valentin Schneider <vschneid@...hat.com>, linux-doc@...r.kernel.org,
linux-kernel@...r.kernel.org, linux-trace-kernel@...r.kernel.org,
linux-kselftest@...r.kernel.org
Subject: Re: [PATCH rcu 10/11] srcu: Add FORCE_NEED_SRCU_NMI_SAFE Kconfig for
testing
On Tue, Mar 25, 2025 at 03:57:43PM +0100, Geert Uytterhoeven wrote:
> Hi Paul,
>
> On Tue, 25 Mar 2025 at 15:36, Paul E. McKenney <paulmck@...nel.org> wrote:
> > On Tue, Mar 25, 2025 at 09:04:31AM +0100, Geert Uytterhoeven wrote:
> > > On Wed, 19 Feb 2025 at 16:44, Boqun Feng <boqun.feng@...il.com> wrote:
> > > > From: "Paul E. McKenney" <paulmck@...nel.org>
> > > >
> > > > The srcu_read_lock_nmisafe() and srcu_read_unlock_nmisafe() functions
> > > > map to __srcu_read_lock() and __srcu_read_unlock() on systems like x86
> > > > that have NMI-safe this_cpu_inc() operations. This makes the underlying
> > > > __srcu_read_lock_nmisafe() and __srcu_read_unlock_nmisafe() functions
> > > > difficult to test on (for example) x86 systems, allowing bugs to creep in.
> > > >
> > > > This commit therefore creates a FORCE_NEED_SRCU_NMI_SAFE Kconfig that
> > > > forces those underlying functions to be used even on systems where they
> > > > are not needed, thus providing better testing coverage.
> > > >
> > > > Signed-off-by: Paul E. McKenney <paulmck@...nel.org>
> > > > Signed-off-by: Boqun Feng <boqun.feng@...il.com>
> > >
> > > Thanks for your patch, which is now commit 536e8b9b80bc7a0a ("srcu:
> > > Add FORCE_NEED_SRCU_NMI_SAFE Kconfig for testing") in linus/master
> > >
> > > > --- a/kernel/rcu/Kconfig
> > > > +++ b/kernel/rcu/Kconfig
> > > > @@ -65,6 +65,17 @@ config TREE_SRCU
> > > > help
> > > > This option selects the full-fledged version of SRCU.
> > > >
> > > > +config FORCE_NEED_SRCU_NMI_SAFE
> > > > + bool "Force selection of NEED_SRCU_NMI_SAFE"
> > >
> > > What am I supposed to answer here? "n" I guess.
> > > What about distro and allmodconfig kernels?
> >
> > Yes, you should select "n" unless ...
> >
> > > > + depends on !TINY_SRCU
> > > > + select NEED_SRCU_NMI_SAFE
> > > > + default n
> > > > + help
> > > > + This option forces selection of the NEED_SRCU_NMI_SAFE
> > > > + Kconfig option, allowing testing of srcu_read_lock_nmisafe()
> > > > + and srcu_read_unlock_nmisafe() on architectures (like x86)
> > > > + that select the ARCH_HAS_NMI_SAFE_THIS_CPU_OPS Kconfig option.
> > >
> > > Perhaps this should depend on ARCH_HAS_NMI_SAFE_THIS_CPU_OPS?
> >
> > ... you are on a system selecting ARCH_HAS_NMI_SAFE_THIS_CPU_OPS and
>
> So a dependency on ARCH_HAS_NMI_SAFE_THIS_CPU_OPS does make sense,
> doesn't it?
The FORCE_NEED_SRCU_NMI_SAFE has no effect otherwise, so it cannot
hurt. Again, please see below.
Thanx, Paul
> > you would like to test the SRCU setup that needed only by systems that
> > do not select ARCH_HAS_NMI_SAFE_THIS_CPU_OPS.
> >
> > Ah. I forgot to add "depends on RCU_EXPERT".
>
> Yes, that makes sense.
>
> > Apologies, I will fix this. Does the patch show below do the trick?
> >
> > Thanx, Paul
-----------------------------------------------------------------------
commit 2245ef8605a80726548253d885b4cadd97f69f3b
Author: Paul E. McKenney <paulmck@...nel.org>
Date: Tue Mar 25 07:31:45 2025 -0700
srcu: Make FORCE_NEED_SRCU_NMI_SAFE depend on RCU_EXPERT
The FORCE_NEED_SRCU_NMI_SAFE is useful only for those wishing to test
the SRCU code paths that accommodate architectures that do not have
NMI-safe per-CPU operations, that is, those architectures that do not
select the ARCH_HAS_NMI_SAFE_THIS_CPU_OPS Kconfig option. As such, this
is a specialized Kconfig option that is not intended for casual users.
This commit therefore hides it behind the RCU_EXPERT Kconfig option.
Given that this new FORCE_NEED_SRCU_NMI_SAFE Kconfig option has no effect
unless the ARCH_HAS_NMI_SAFE_THIS_CPU_OPS Kconfig option is also selected,
it also depends on this Kconfig option.
[ paulmck: Apply Geert Uytterhoeven feedback. ]
Reported-by: Geert Uytterhoeven <geert@...ux-m68k.org>
Closes: https://lore.kernel.org/all/CAMuHMdX6dy9_tmpLkpcnGzxyRbe6qSWYukcPp=H1GzZdyd3qBQ@mail.gmail.com/
Signed-off-by: Paul E. McKenney <paulmck@...nel.org>
diff --git a/kernel/rcu/Kconfig b/kernel/rcu/Kconfig
index b3f985d41717a..ceaf6594f634c 100644
--- a/kernel/rcu/Kconfig
+++ b/kernel/rcu/Kconfig
@@ -68,6 +68,8 @@ config TREE_SRCU
config FORCE_NEED_SRCU_NMI_SAFE
bool "Force selection of NEED_SRCU_NMI_SAFE"
depends on !TINY_SRCU
+ depends on RCU_EXPERT
+ depends on ARCH_HAS_NMI_SAFE_THIS_CPU_OPS
select NEED_SRCU_NMI_SAFE
default n
help
Powered by blists - more mailing lists