[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <2ba5baa2-3598-4499-bd88-b7fc139f6ad8@paulmck-laptop>
Date: Tue, 3 Oct 2023 11:15:21 -0700
From: "Paul E. McKenney" <paulmck@...nel.org>
To: Steven Rostedt <rostedt@...dmis.org>
Cc: Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
linux-kernel@...r.kernel.org,
Michael Jeanson <mjeanson@...icios.com>,
Peter Zijlstra <peterz@...radead.org>,
Alexei Starovoitov <ast@...nel.org>,
Yonghong Song <yhs@...com>, Ingo Molnar <mingo@...hat.com>,
Arnaldo Carvalho de Melo <acme@...nel.org>,
Mark Rutland <mark.rutland@....com>,
Alexander Shishkin <alexander.shishkin@...ux.intel.com>,
Jiri Olsa <jolsa@...hat.com>,
Namhyung Kim <namhyung@...nel.org>, bpf@...r.kernel.org,
Joel Fernandes <joel@...lfernandes.org>
Subject: Re: [RFC PATCH v3 1/5] tracing: Introduce faultable tracepoints (v3)
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@...nel.org> 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@...nel.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?
>
> Reviewed-by: Steven Rostedt (Google) <rostedt@...dmis.org>
>
> Link: https://lore.kernel.org/all/20231002211936.5948253e@gandalf.local.home/
Thank you both! Updated as shown below.
Thanx, Paul
------------------------------------------------------------------------
commit 4d2115e8919760c690e30f48cae2f017c1581546
Author: Paul E. McKenney <paulmck@...nel.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.
Link: https://lore.kernel.org/all/20231002211936.5948253e@gandalf.local.home/
Reported-by: Steven Rostedt <rostedt@...dmis.org>
Signed-off-by: Paul E. McKenney <paulmck@...nel.org>
Reviewed-by: Mathieu Desnoyers <mathieu.desnoyers@...icios.com>
Reviewed-by: Steven Rostedt (Google) <rostedt@...dmis.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,
Powered by blists - more mailing lists