[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <20220921144620.GA1200846@paulmck-ThinkPad-P17-Gen-1>
Date: Wed, 21 Sep 2022 07:46:20 -0700
From: "Paul E. McKenney" <paulmck@...nel.org>
To: rcu@...r.kernel.org
Cc: linux-kernel@...r.kernel.org, kernel-team@...com,
rostedt@...dmis.org, tglx@...utronix.de, john.ogness@...utronix.de,
pmladek@...e.com
Subject: [PATCH rcu 0/4] NMI-safe SRCU reader API
Hello!
This RFC series provides an NMI-safe SRCU reader API in the guise
of srcu_read_lock_nmisafe() and srcu_read_unlock_nmisafe(). 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.
The series is as follows:
1. Convert ->srcu_lock_count and ->srcu_unlock_count to atomic.
2. Create and 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.
Thanx, Paul
------------------------------------------------------------------------
b/include/linux/srcu.h | 37 ++++++++++++++++++++
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 +++++++++++++++++++++++++++++++++++++++------
10 files changed, 160 insertions(+), 32 deletions(-)
Powered by blists - more mailing lists