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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20231002211936.5948253e@gandalf.local.home>
Date:   Mon, 2 Oct 2023 21:19:36 -0400
From:   Steven Rostedt <rostedt@...dmis.org>
To:     "Paul E. McKenney" <paulmck@...nel.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, 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.

-- Steve