linux-kernel - Re: [PATCH rcu 10/11] srcu: Add FORCE_NEED_SRCU_NMI

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAMuHMdX6dy9_tmpLkpcnGzxyRbe6qSWYukcPp=H1GzZdyd3qBQ@mail.gmail.com>
Date: Tue, 25 Mar 2025 09:04:31 +0100
From: Geert Uytterhoeven <geert@...ux-m68k.org>
To: Boqun Feng <boqun.feng@...il.com>, "Paul E. McKenney" <paulmck@...nel.org>
Cc: 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

Hi Boqun, Paul,

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?

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

> +
>  config NEED_SRCU_NMI_SAFE
>         def_bool HAVE_NMI && !ARCH_HAS_NMI_SAFE_THIS_CPU_OPS && !TINY_SRCU

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@...ux-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