Messages in this thread | | | Date | Tue, 3 Oct 2023 13:37:26 -0400 | Subject | Re: [RFC PATCH v3 1/5] tracing: Introduce faultable tracepoints (v3) | From | Mathieu Desnoyers <> |
| |
On 10/3/23 13:33, Paul E. McKenney 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@kernel.org> 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? > > Thanx, Paul > > ------------------------------------------------------------------------ > > commit 973eb79ec46c16f13bb5b47ad14d44a1f1c79dc9 > Author: Paul E. McKenney <paulmck@kernel.org> > 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. >
Reviewed-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Thanks!
Mathieu
> Reported-by: Steven Rostedt <rostedt@goodmis.org> > Signed-off-by: Paul E. McKenney <paulmck@kernel.org> > > 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,
-- Mathieu Desnoyers EfficiOS Inc. https://www.efficios.com
| |