tjh.dev / kernel
Linux kernel mirror (for testing) git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
kernel os linux
1
fork

Configure Feed

Select the types of activity you want to include in your feed.

srcu: Improve comments about acceleration leak

The comments added in commit 1ef990c4b36b ("srcu: No need to
advance/accelerate if no callback enqueued") are a bit confusing.
The comments are describing a scenario for code that was moved and is
no longer the way it was (snapshot after advancing). Improve the code
comments to reflect this and also document why acceleration can never
fail.

Cc: Frederic Weisbecker <frederic@kernel.org>
Cc: Neeraj Upadhyay <neeraj.iitr10@gmail.com>
Reviewed-by: Frederic Weisbecker <frederic@kernel.org>
Signed-off-by: Joel Fernandes (Google) <joel@joelfernandes.org>
Reviewed-by: Paul E. McKenney <paulmck@kernel.org>
Signed-off-by: Boqun Feng <boqun.feng@gmail.com>

authored by

Joel Fernandes (Google) and committed by
Boqun Feng 67050837 7f66f099

+20 -4
+20 -4
kernel/rcu/srcutree.c
··· 1234 1234 if (rhp) 1235 1235 rcu_segcblist_enqueue(&sdp->srcu_cblist, rhp); 1236 1236 /* 1237 - * The snapshot for acceleration must be taken _before_ the read of the 1238 - * current gp sequence used for advancing, otherwise advancing may fail 1239 - * and acceleration may then fail too. 1237 + * It's crucial to capture the snapshot 's' for acceleration before 1238 + * reading the current gp_seq that is used for advancing. This is 1239 + * essential because if the acceleration snapshot is taken after a 1240 + * failed advancement attempt, there's a risk that a grace period may 1241 + * conclude and a new one may start in the interim. If the snapshot is 1242 + * captured after this sequence of events, the acceleration snapshot 's' 1243 + * could be excessively advanced, leading to acceleration failure. 1244 + * In such a scenario, an 'acceleration leak' can occur, where new 1245 + * callbacks become indefinitely stuck in the RCU_NEXT_TAIL segment. 1246 + * Also note that encountering advancing failures is a normal 1247 + * occurrence when the grace period for RCU_WAIT_TAIL is in progress. 1240 1248 * 1241 - * This could happen if: 1249 + * To see this, consider the following events which occur if 1250 + * rcu_seq_snap() were to be called after advance: 1242 1251 * 1243 1252 * 1) The RCU_WAIT_TAIL segment has callbacks (gp_num = X + 4) and the 1244 1253 * RCU_NEXT_READY_TAIL also has callbacks (gp_num = X + 8). ··· 1273 1264 if (rhp) { 1274 1265 rcu_segcblist_advance(&sdp->srcu_cblist, 1275 1266 rcu_seq_current(&ssp->srcu_sup->srcu_gp_seq)); 1267 + /* 1268 + * Acceleration can never fail because the base current gp_seq 1269 + * used for acceleration is <= the value of gp_seq used for 1270 + * advancing. This means that RCU_NEXT_TAIL segment will 1271 + * always be able to be emptied by the acceleration into the 1272 + * RCU_NEXT_READY_TAIL or RCU_WAIT_TAIL segments. 1273 + */ 1276 1274 WARN_ON_ONCE(!rcu_segcblist_accelerate(&sdp->srcu_cblist, s)); 1277 1275 } 1278 1276 if (ULONG_CMP_LT(sdp->srcu_gp_seq_needed, s)) {