From: David Vernet <void@manifault.com>
To: frederic@kernel.org, jiangshanlai@gmail.com,
joel@joelfernandes.org, josh@joshtriplett.org,
linux-kernel@vger.kernel.org, mathieu.desnoyers@efficios.com,
paulmck@kernel.org, quic_neeraju@quicinc.com,
rcu@vger.kernel.org, rostedt@goodmis.org
Subject: [PATCH] rcu_sync: Fix comment to properly reflect rcu_sync_exit() behavior
Date: Tue, 29 Mar 2022 15:26:13 -0700 [thread overview]
Message-ID: <20220329222612.1001586-1-void@manifault.com> (raw)
rcu_sync_enter() is an rcu_sync API used by updaters which forces RCU
readers (e.g. percpu-rwsem) to take a slow-path during an update. It does
this by setting the gp_state of the rcu_sync object to GP_ENTER (i.e. > 0).
In this state, readers will take a "slow path", such as having percpu-rwsem
readers wait on a semaphore rather than just incrementing a reader count.
When the updater has completed their work, they must invoke rcu_sync_exit()
to signal to readers that they may again take their fastpaths.
rcu_sync_enter() currently has a comment that stipulates that a later call
to rcu_sync_exit() (by an updater) will re-enable reader "slowpaths". This
patch corrects the comment to properly reflect that rcu_sync_exit()
re-enables reader fastpaths.
Signed-off-by: David Vernet <void@manifault.com>
---
kernel/rcu/sync.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/rcu/sync.c b/kernel/rcu/sync.c
index 33d896d85902..5cefc702158f 100644
--- a/kernel/rcu/sync.c
+++ b/kernel/rcu/sync.c
@@ -111,7 +111,7 @@ static void rcu_sync_func(struct rcu_head *rhp)
* a slowpath during the update. After this function returns, all
* subsequent calls to rcu_sync_is_idle() will return false, which
* tells readers to stay off their fastpaths. A later call to
- * rcu_sync_exit() re-enables reader slowpaths.
+ * rcu_sync_exit() re-enables reader fastpaths.
*
* When called in isolation, rcu_sync_enter() must wait for a grace
* period, however, closely spaced calls to rcu_sync_enter() can
--
2.30.2
next reply other threads:[~2022-03-29 22:26 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-03-29 22:26 David Vernet [this message]
2022-03-29 23:22 ` [PATCH] rcu_sync: Fix comment to properly reflect rcu_sync_exit() behavior Paul E. McKenney
2022-03-29 19:36 ` David Vernet
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=20220329222612.1001586-1-void@manifault.com \
--to=void@manifault.com \
--cc=frederic@kernel.org \
--cc=jiangshanlai@gmail.com \
--cc=joel@joelfernandes.org \
--cc=josh@joshtriplett.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mathieu.desnoyers@efficios.com \
--cc=paulmck@kernel.org \
--cc=quic_neeraju@quicinc.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