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: <20231003133856.2879f36f@gandalf.local.home>
Date:   Tue, 3 Oct 2023 13:38:56 -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 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/

-- Steve


> 
> 							Thanx, Paul
> 
> ------------------------------------------------------------------------
> 
> commit 973eb79ec46c16f13bb5b47ad14d44a1f1c79dc9
> 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.
>     
>     Reported-by: Steven Rostedt <rostedt@...dmis.org>
>     Signed-off-by: Paul E. McKenney <paulmck@...nel.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,