[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <5d0771e9-332c-42cd-acf3-53d46bb691f3@paulmck-laptop>
Date: Tue, 3 Oct 2023 06:44:50 -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 Mon, Oct 02, 2023 at 09:19:36PM -0400, Steven Rostedt wrote:
> On Mon, 2 Oct 2023 17:14:39 -0700
> "Paul E. McKenney" <paulmck@...nel.org> wrote:
>
> > On Mon, Oct 02, 2023 at 07:10:23PM -0400, Steven Rostedt wrote:
> > > On Mon, 2 Oct 2023 16:25:27 -0400
> > > Mathieu Desnoyers <mathieu.desnoyers@...icios.com> wrote:
> > >
> > > > @@ -202,8 +198,12 @@ static inline struct tracepoint *tracepoint_ptr_deref(tracepoint_ptr_t *p)
> > > > if (WARN_ON_ONCE(RCUIDLE_COND(rcuidle))) \
> > > > return; \
> > > > \
> > > > - /* keep srcu and sched-rcu usage consistent */ \
> > > > - preempt_disable_notrace(); \
> > > > + if (mayfault) { \
> > > > + rcu_read_lock_trace(); \
> > >
> > > I thought rcu_trace was for the case that a task can not voluntarily call
> > > schedule. If this tracepoint tries to read user space memory that isn't
> > > paged in, and faults, can't the faulting logic call schedule and break this
> > > requirement?
> >
> > Well, additional new uses of rcu_read_lock_trace() do bear close scrutiny,
> > but RCU Tasks Trace readers are permitted to block for page faults.
> > The BPF folks already use it for this purpose, so this should be OK.
> > (If for some unknown-to-me reason it isn't, I am sure that Alexei,
> > who is on CC, will not suffer in silence.)
> >
> > One way of thinking of RCU Tasks Trace is as a form of SRCU with
> > lightweight readers. Except that, unlike SRCU, there is only one global
> > RCU Tasks Trace. This means that all RCU Tasks Trace users need to keep
> > each other informed, because one users' unruly readers will affect all
> > RCU Tasks Trace users.
> >
> > But given that the BPF folks already have page faults in RCU Tasks Trace
> > readers, this one should be OK.
>
> Then I think we should update the documentation.
>
> From: Documentation/RCU/checklist.rst:
>
> 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().
>
> Because it's all one paragraph it's a bit confusing to know what uses what.
> Perhaps it should be broken up a bit more?
>
> 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().
>
> 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?
Thanx, Paul
Powered by blists - more mailing lists