Re: [RFC PATCH v3 1/5] tracing: Introduce faultable tracepoints (v3)

[Paul E. McKenney]

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@xxxxxxxxxxxx> 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.

							Thanx, Paul

> -- Steve
> 
> 
> > +		} else {						\
> > +			/* keep srcu and sched-rcu usage consistent */	\
> > +			preempt_disable_notrace();			\
> > +		}							\
> >  									\
> >  		/*							\
> >  		 * For rcuidle callers, use srcu since sched-rcu	\