Hi Boqun, Paul,
On Wed, 19 Feb 2025 at 16:44, Boqun Feng <boqun.feng@xxxxxxxxx> wrote:
> From: "Paul E. McKenney" <paulmck@xxxxxxxxxx>
>
> 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@xxxxxxxxxx>
> Signed-off-by: Boqun Feng <boqun.feng@xxxxxxxxx>
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@xxxxxxxxxxxxxx
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
