On Tue, Oct 03, 2023 at 01:38:56PM -0400, Steven Rostedt wrote: > On Tue, 3 Oct 2023 10:33:33 -0700 > "Paul E. McKenney" <paulmck@xxxxxxxxxx> wrote: > > > On Tue, Oct 03, 2023 at 10:08:54AM -0400, Steven Rostedt wrote: > > > On Tue, 3 Oct 2023 06:44:50 -0700 > > > "Paul E. McKenney" <paulmck@xxxxxxxxxx> wrote: > > > > > > > > That way it is clear what uses what, as I read the original paragraph a > > > > > couple of times and could have sworn that rcu_read_lock_trace() required > > > > > tasks to not block. > > > > > > > > That would work for me. Would you like to send a patch, or would you > > > > rather we made the adjustments? > > > > > > Which ever. > > > > OK, how about like this? > > Reviewed-by: Steven Rostedt (Google) <rostedt@xxxxxxxxxxx> > > Link: https://lore.kernel.org/all/20231002211936.5948253e@xxxxxxxxxxxxxxxxxx/ Thank you both! Updated as shown below. Thanx, Paul ------------------------------------------------------------------------ commit 4d2115e8919760c690e30f48cae2f017c1581546 Author: Paul E. McKenney <paulmck@xxxxxxxxxx> Date: Tue Oct 3 10:30:01 2023 -0700 doc: Clarify RCU Tasks reader/updater checklist Currently, the reader/updater compatibility rules for the three RCU Tasks flavors are squished together in a single paragraph, which can result in confusion. This commit therefore splits them out into a list, clearly showing the distinction between these flavors. Link: https://lore.kernel.org/all/20231002211936.5948253e@xxxxxxxxxxxxxxxxxx/ Reported-by: Steven Rostedt <rostedt@xxxxxxxxxxx> Signed-off-by: Paul E. McKenney <paulmck@xxxxxxxxxx> Reviewed-by: Mathieu Desnoyers <mathieu.desnoyers@xxxxxxxxxxxx> Reviewed-by: Steven Rostedt (Google) <rostedt@xxxxxxxxxxx> diff --git a/Documentation/RCU/checklist.rst b/Documentation/RCU/checklist.rst index bd3c58c44bef..c432899aff22 100644 --- a/Documentation/RCU/checklist.rst +++ b/Documentation/RCU/checklist.rst @@ -241,15 +241,22 @@ over a rather long period of time, but improvements are always welcome! srcu_struct. The rules for the expedited RCU grace-period-wait primitives are the same as for their non-expedited counterparts. - If the updater uses call_rcu_tasks() or synchronize_rcu_tasks(), - then the readers must refrain from executing voluntary - context switches, that is, from blocking. If the updater uses - call_rcu_tasks_trace() or synchronize_rcu_tasks_trace(), then - the corresponding readers must use rcu_read_lock_trace() and - rcu_read_unlock_trace(). If an updater uses call_rcu_tasks_rude() - or synchronize_rcu_tasks_rude(), then the corresponding readers - must use anything that disables preemption, for example, - preempt_disable() and preempt_enable(). + Similarly, it is necssary to correctly use the RCU Tasks flavors: + + a. If the updater uses synchronize_rcu_tasks() or + call_rcu_tasks(), then the readers must refrain from + executing voluntary context switches, that is, from + blocking. + + b. If the updater uses call_rcu_tasks_trace() + or synchronize_rcu_tasks_trace(), then the + corresponding readers must use rcu_read_lock_trace() + and rcu_read_unlock_trace(). + + c. If an updater uses call_rcu_tasks_rude() or + synchronize_rcu_tasks_rude(), then the corresponding + readers must use anything that disables preemption, + for example, preempt_disable() and preempt_enable(). Mixing things up will result in confusion and broken kernels, and has even resulted in an exploitable security issue. Therefore,
