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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox