linux-kernel - Re: [PATCH rcu 1/2] docs: Add documentation for rude and trace RCU flavors

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: <20220420121906.13752d3e@gandalf.local.home>
Date:   Wed, 20 Apr 2022 12:19:06 -0400
From:   Steven Rostedt <rostedt@...dmis.org>
To:     "Paul E. McKenney" <paulmck@...nel.org>
Cc:     rcu@...r.kernel.org, linux-kernel@...r.kernel.org,
        kernel-team@...com
Subject: Re: [PATCH rcu 1/2] docs: Add documentation for rude and trace RCU
 flavors

On Wed, 20 Apr 2022 09:13:19 -0700
"Paul E. McKenney" <paulmck@...nel.org> wrote:

> > > +The tasks-rude-RCU API is also reader-marking-free and thus quite compact,
> > > +consisting of call_rcu_tasks_rude(), synchronize_rcu_tasks_rude(),
> > > +and rcu_barrier_tasks_rude().  
> > 
> > Are we going to be able to get rid of the "rude" version once we have all
> > tracing in a RCU visible section?  
> 
> You tell me!  ;-)
> 
> If there are no longer any users, I would be happy to get rid of it.
> As of v5.18-rc1, the only user is ftrace.
> 
> > > +
> > > +Tasks Trace RCU
> > > +~~~~~~~~~~~~~~~
> > > +
> > > +Some forms of tracing need to sleep in readers, but cannot tolerate
> > > +SRCU's read-side overhead, which includes a full memory barrier in both
> > > +srcu_read_lock() and srcu_read_unlock().  This need is handled by a
> > > +Tasks Trace RCU that uses scheduler locking and IPIs to synchronize with
> > > +readers.  Real-time systems that cannot tolerate IPIs may build their
> > > +kernels with ``CONFIG_TASKS_TRACE_RCU_READ_MB=y``, which avoids the IPIs at
> > > +the expense of adding full memory barriers to the read-side primitives.  
> > 
> > If NOHZ_FULL is enabled, is there a way to also be able to have this full
> > mb on RT removed as well?
> >   

Hmm, if we no longer need the rude version due to noinstr, if then we need
to use something that adds full memory barriers at *every function call*
then I rather keep the rude version.

-- Steve