From: "Paul E. McKenney" <paulmck@kernel.org>
To: rcu@vger.kernel.org
Cc: linux-kernel@vger.kernel.org, kernel-team@fb.com,
rostedt@goodmis.org, "Paul E. McKenney" <paulmck@kernel.org>,
Maxim Mikityanskiy <maximmi@nvidia.com>
Subject: [PATCH rcu 06/10] rcu: Update rcu_access_pointer() header for rcu_dereference_protected()
Date: Wed, 31 Aug 2022 11:08:01 -0700 [thread overview]
Message-ID: <20220831180805.2693546-6-paulmck@kernel.org> (raw)
In-Reply-To: <20220831180759.GA2693289@paulmck-ThinkPad-P17-Gen-1>
The rcu_access_pointer() docbook header correctly notes that it may be
used during post-grace-period teardown. However, it is usually better to
use rcu_dereference_protected() for this purpose. This commit therefore
calls out this preferred usage.
Reported-by: Maxim Mikityanskiy <maximmi@nvidia.com>
Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
---
include/linux/rcupdate.h | 18 +++++++++++++-----
1 file changed, 13 insertions(+), 5 deletions(-)
diff --git a/include/linux/rcupdate.h b/include/linux/rcupdate.h
index f527f27e64387..61a1a85c720c3 100644
--- a/include/linux/rcupdate.h
+++ b/include/linux/rcupdate.h
@@ -496,13 +496,21 @@ do { \
* against NULL. Although rcu_access_pointer() may also be used in cases
* where update-side locks prevent the value of the pointer from changing,
* you should instead use rcu_dereference_protected() for this use case.
+ * Within an RCU read-side critical section, there is little reason to
+ * use rcu_access_pointer().
+ *
+ * It is usually best to test the rcu_access_pointer() return value
+ * directly in order to avoid accidental dereferences being introduced
+ * by later inattentive changes. In other words, assigning the
+ * rcu_access_pointer() return value to a local variable results in an
+ * accident waiting to happen.
*
* It is also permissible to use rcu_access_pointer() when read-side
- * access to the pointer was removed at least one grace period ago, as
- * is the case in the context of the RCU callback that is freeing up
- * the data, or after a synchronize_rcu() returns. This can be useful
- * when tearing down multi-linked structures after a grace period
- * has elapsed.
+ * access to the pointer was removed at least one grace period ago, as is
+ * the case in the context of the RCU callback that is freeing up the data,
+ * or after a synchronize_rcu() returns. This can be useful when tearing
+ * down multi-linked structures after a grace period has elapsed. However,
+ * rcu_dereference_protected() is normally preferred for this use case.
*/
#define rcu_access_pointer(p) __rcu_access_pointer((p), __UNIQUE_ID(rcu), __rcu)
--
2.31.1.189.g2e36527f23
next prev parent reply other threads:[~2022-08-31 18:08 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-08-31 18:07 [PATCH rcu 0/7] Miscellaneous fixes for v6.1 Paul E. McKenney
2022-08-31 18:07 ` [PATCH rcu 01/10] rcu: Fix rcu_read_unlock_strict() strict QS reporting Paul E. McKenney
2022-08-31 18:07 ` [PATCH rcu 02/10] rcu: Update rcu_preempt_deferred_qs() comments for !PREEMPT kernels Paul E. McKenney
2022-08-31 18:07 ` [PATCH rcu 03/10] rcu: Add QS check in rcu_exp_handler() for non-preemptible kernels Paul E. McKenney
2022-09-07 12:10 ` Frederic Weisbecker
2022-09-07 14:57 ` Paul E. McKenney
2022-09-07 15:14 ` Frederic Weisbecker
2022-08-31 18:07 ` [PATCH rcu 04/10] rcu: Make tiny RCU support leak callbacks for debug-object errors Paul E. McKenney
2022-08-31 18:08 ` [PATCH rcu 05/10] rcu: Document reason for rcu_all_qs() call to preempt_disable() Paul E. McKenney
2022-08-31 18:08 ` Paul E. McKenney [this message]
2022-08-31 18:08 ` [PATCH rcu 07/10] sched/debug: Try trigger_single_cpu_backtrace(cpu) in dump_cpu_task() Paul E. McKenney
2022-08-31 18:08 ` [PATCH rcu 08/10] sched/debug: Show the registers of 'current' " Paul E. McKenney
2022-08-31 18:08 ` [PATCH rcu 09/10] rcu: Avoid triggering strict-GP irq-work when RCU is idle Paul E. McKenney
2022-08-31 18:08 ` [PATCH rcu 10/10] rcu: Exclude outgoing CPU when it is the last to leave Paul E. McKenney
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20220831180805.2693546-6-paulmck@kernel.org \
--to=paulmck@kernel.org \
--cc=kernel-team@fb.com \
--cc=linux-kernel@vger.kernel.org \
--cc=maximmi@nvidia.com \
--cc=rcu@vger.kernel.org \
--cc=rostedt@goodmis.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.