[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAEXW_YTBOM--SF0JDGmsa4sj5PmA6Zjx-b9t-4gfLtGkxhnHUQ@mail.gmail.com>
Date: Fri, 14 Oct 2022 18:52:13 -0400
From: Joel Fernandes <joel@...lfernandes.org>
To: "Paul E. McKenney" <paulmck@...nel.org>
Cc: rcu@...r.kernel.org, linux-kernel@...r.kernel.org,
kernel-team@...com, rostedt@...dmis.org, tglx@...utronix.de,
john.ogness@...utronix.de, pmladek@...e.com
Subject: Re: [PATCH v2 rcu 0/8] NMI-safe SRCU reader API
On Fri, Oct 14, 2022 at 6:47 PM Joel Fernandes <joel@...lfernandes.org> wrote:
>
> On Thu, Sep 29, 2022 at 11:07:14AM -0700, Paul E. McKenney wrote:
> > Hello!
> >
> > This RFC series provides the second version of an NMI-safe SRCU reader API
> > in the guise of srcu_read_lock_nmisafe() and srcu_read_unlock_nmisafe().
>
> Just a comment about high-level use of the new NMI-safe SRCU api: say if for
> certain arch, NMI cannot be interrupted (by breakpoint or something), then
> using NMI-safe API will force such arch to potentially use more expensive RMW
> atomic than the previously cheap local non-atomic operations that the arch
> was able to get away with.
>
> Thoughts? Otherwise, LGTM.
>
I take it back. You are indeed guarding it correctly as below. I got
confused by another patch that was doing debug checking even for arch
that does not need it (which is a good thing).
+config NEED_SRCU_NMI_SAFE
+ def_bool HAVE_NMI && !ARCH_HAS_NMI_SAFE_THIS_CPU_OPS && !TINY_SRCU
+
Thanks!
- Joel
> thanks,
>
> - Joel
>
>
> > A given srcu_struct structure must use either the traditional
> > srcu_read_lock() and srcu_read_unlock() API or the new _nmisafe() API:
> > Mixing and matching is not permitted. So much so that kernels built
> > with CONFIG_PROVE_RCU=y will complain if you try it.
> >
> > The reason for this restriction is that I have yet to find a use case
> > that is not a accident waiting to happen. And if free intermixing
> > were permitted, it is pretty much a given that someone somewhere will
> > get confused and use srcu_read_lock_nmisafe() within NMI handlers and
> > srcu_read_lock() elsewhere, which will not (repeat, NOT) provide NMI
> > safety.
> >
> > I do not expect to push this into the v6.1 merge window. However, if
> > the printk() series that needs it goes in, then I will push it as a fix
> > for the resulting regression.
> >
> > The series is as follows:
> >
> > 1. Convert ->srcu_lock_count and ->srcu_unlock_count to atomic.
> >
> > 2. Create an srcu_read_lock_nmisafe() and srcu_read_unlock_nmisafe().
> >
> > 3. Check for consistent per-CPU per-srcu_struct NMI safety.
> >
> > 4. Check for consistent global per-srcu_struct NMI safety.
> >
> > 5. Add ARCH_HAS_NMI_SAFE_THIS_CPU_OPS Kconfig option.
> >
> > 6. Add ARCH_HAS_NMI_SAFE_THIS_CPU_OPS Kconfig option.
> >
> > 7. Add ARCH_HAS_NMI_SAFE_THIS_CPU_OPS Kconfig option.
> >
> > 8. Add ARCH_HAS_NMI_SAFE_THIS_CPU_OPS Kconfig option.
> >
> > Changes since v1 RFC:
> >
> > 1. Added enabling patches for arm64, loongarch, s390, and x86.
> > These have what appear to me to be NMI-safe this_cpu_inc()
> > implementations.
> >
> > 2. Fix a build error on !SMP kernels built without SRCU.
> >
> > 3. Fix a build error on !SMP kernels.
> >
> > Thanx, Paul
> >
> > ------------------------------------------------------------------------
> >
> > b/arch/arm64/Kconfig | 1
> > b/arch/loongarch/Kconfig | 1
> > b/arch/s390/Kconfig | 1
> > b/arch/x86/Kconfig | 1
> > b/include/linux/srcu.h | 39 +++++++++++++++++++++
> > b/include/linux/srcutiny.h | 11 ++++++
> > b/include/linux/srcutree.h | 4 +-
> > b/kernel/rcu/Kconfig | 3 +
> > b/kernel/rcu/rcutorture.c | 11 ++++--
> > b/kernel/rcu/srcutree.c | 24 ++++++-------
> > include/linux/srcu.h | 4 +-
> > include/linux/srcutiny.h | 4 +-
> > include/linux/srcutree.h | 12 +++++-
> > kernel/rcu/srcutree.c | 82 +++++++++++++++++++++++++++++++++++++++------
> > 14 files changed, 166 insertions(+), 32 deletions(-)
Powered by blists - more mailing lists