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: <20220420140226.32a10ece@gandalf.local.home>
Date:   Wed, 20 Apr 2022 14:02:26 -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:48:47 -0700
"Paul E. McKenney" <paulmck@...nel.org> wrote:

> > > > If NOHZ_FULL is enabled, is there a way to also be able to have this full
> > > > mb on RT removed as well?  
> 
> Ah, I did miss this question, apologies.  The tradeoff is IPIs during
> each Tasks Trace RCU grace period on the one hand or the read-side
> memory barrier on the other.
> 
> CONFIG_TASKS_TRACE_RCU_READ_MB=y gets you the read-side memory barriers.
> 
> CONFIG_TASKS_TRACE_RCU_READ_MB=n gets you the IPIs.
> 
> Choose wisely!  ;-)

Yes, I figured this part.

> 
> More seriously, I could easily imagine an RT system being set up so that
> Tasks Trace RCU grace periods never happen while the real-time application
> is running.  This requires the system administrator being careful what
> tracing facilities are used that those application is running, but
> it seems doable to me.

Not something I would want to put onto the system administrator.

> 
> Such an RT system could build with CONFIG_TASKS_TRACE_RCU_READ_MB=n to
> avoid the read-side memory barriers, but also avoiding the IPIs while
> the application was running.
> 
> Even more seriously, if the real-time application runs in nohz_full mode,
> Tasks Trace RCU will avoid IPIing it.  In that case, the kernel can be
> built with CONFIG_TASKS_TRACE_RCU_READ_MB=n and avoid both the read-side
> memory barriers and the IPIs.

Is this currently the case?

> 
> And the final bit of seriousness for this email, if your real-time
> application didn't have a time-critical CPU-bound component, it might
> be possible to avoid both read-side memory barriers and IPIs by
> adjusting the rcu_tasks_trace_qs() code in the context-switch hook.
> 
> > 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.  
> 
> A full memory barrier at every function call does sound more heavy weight
> than would be good.  ;-)

Hmm, I just realized that the function tracer can not use any "reader side"
tracing. Thus, I wonder if we can modify the rude side to be a bit less
rude? That is, what can be changed if the reader always happens inside an
"RCU is watching" location but still has the requirement that it can not
tell RCU it started "reading" and allows preemption?

The issue with function tracing is that the "read side" starts at the
location that calls the trampoline (aka fentry or mcount call). Where it's
either a nop or a call to the trampoline. To free the trampoline, we would
still need to wait for all locations watched by RCU to schedule. Would it
still be rude to do so? That is, we do not need to worry about idle tasks
nor NOHZ_FULL tasks.

-- Steve