[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <20230105002853.1769401-5-paulmck@kernel.org>
Date: Wed, 4 Jan 2023 16:28:49 -0800
From: "Paul E. McKenney" <paulmck@...nel.org>
To: rcu@...r.kernel.org
Cc: linux-kernel@...r.kernel.org, kernel-team@...a.com,
rostedt@...dmis.org, "Paul E. McKenney" <paulmck@...nel.org>,
Jan Kara <jack@...e.cz>, Amir Goldstein <amir73il@...il.com>
Subject: [PATCH rcu 5/9] rcu: Add srcu_down_read() and srcu_up_read()
A pair of matching srcu_read_lock() and srcu_read_unlock() invocations
must take place within the same context, for example, within the same
task. Otherwise, lockdep complains, as is the right thing to do for
most use cases.
However, there are use cases involving asynchronous I/O where the
SRCU reader needs to begin on one task and end on another. This commit
therefore supplies the semaphore-like srcu_down_read() and srcu_up_read(),
which act like srcu_read_lock() and srcu_read_unlock(), but permitting
srcu_up_read() to be invoked in a different context than was the matching
srcu_down_read().
Neither srcu_down_read() nor srcu_up_read() may be invoked from an
NMI handler.
Reported-by: Jan Kara <jack@...e.cz>
Signed-off-by: Paul E. McKenney <paulmck@...nel.org>
Tested-by: Amir Goldstein <amir73il@...il.com>
---
include/linux/srcu.h | 45 ++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 45 insertions(+)
diff --git a/include/linux/srcu.h b/include/linux/srcu.h
index 9b9d0bbf1d3cf..74796cd7e7a9d 100644
--- a/include/linux/srcu.h
+++ b/include/linux/srcu.h
@@ -214,6 +214,34 @@ srcu_read_lock_notrace(struct srcu_struct *ssp) __acquires(ssp)
return retval;
}
+/**
+ * srcu_down_read - register a new reader for an SRCU-protected structure.
+ * @ssp: srcu_struct in which to register the new reader.
+ *
+ * Enter a semaphore-like SRCU read-side critical section. Note that
+ * SRCU read-side critical sections may be nested. However, it is
+ * illegal to call anything that waits on an SRCU grace period for the
+ * same srcu_struct, whether directly or indirectly. Please note that
+ * one way to indirectly wait on an SRCU grace period is to acquire
+ * a mutex that is held elsewhere while calling synchronize_srcu() or
+ * synchronize_srcu_expedited(). But if you want lockdep to help you
+ * keep this stuff straight, you should instead use srcu_read_lock().
+ *
+ * The semaphore-like nature of srcu_down_read() means that the matching
+ * srcu_up_read() can be invoked from some other context, for example,
+ * from some other task or from an irq handler. However, neither
+ * srcu_down_read() nor srcu_up_read() may be invoked from an NMI handler.
+ *
+ * Calls to srcu_down_read() may be nested, similar to the manner in
+ * which calls to down_read() may be nested.
+ */
+static inline int srcu_down_read(struct srcu_struct *ssp) __acquires(ssp)
+{
+ WARN_ON_ONCE(in_nmi());
+ srcu_check_nmi_safety(ssp, false);
+ return __srcu_read_lock(ssp);
+}
+
/**
* srcu_read_unlock - unregister a old reader from an SRCU-protected structure.
* @ssp: srcu_struct in which to unregister the old reader.
@@ -254,6 +282,23 @@ srcu_read_unlock_notrace(struct srcu_struct *ssp, int idx) __releases(ssp)
__srcu_read_unlock(ssp, idx);
}
+/**
+ * srcu_up_read - unregister a old reader from an SRCU-protected structure.
+ * @ssp: srcu_struct in which to unregister the old reader.
+ * @idx: return value from corresponding srcu_read_lock().
+ *
+ * Exit an SRCU read-side critical section, but not necessarily from
+ * the same context as the maching srcu_down_read().
+ */
+static inline void srcu_up_read(struct srcu_struct *ssp, int idx)
+ __releases(ssp)
+{
+ WARN_ON_ONCE(idx & ~0x1);
+ WARN_ON_ONCE(in_nmi());
+ srcu_check_nmi_safety(ssp, false);
+ __srcu_read_unlock(ssp, idx);
+}
+
/**
* smp_mb__after_srcu_read_unlock - ensure full ordering after srcu_read_unlock
*
--
2.31.1.189.g2e36527f23
Powered by blists - more mailing lists