linux-kernel - Re: [PATCH tip/core/rcu 3/4] rcu-tasks: Make ksoftirqd provide RCU Tasks quiescent states

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: <20210513142110.GY975577@paulmck-ThinkPad-P17-Gen-1>
Date:   Thu, 13 May 2021 07:21:10 -0700
From:   "Paul E. McKenney" <paulmck@...nel.org>
To:     Masami Hiramatsu <mhiramat@...nel.org>
Cc:     rcu@...r.kernel.org, linux-kernel@...r.kernel.org,
        kernel-team@...com, mingo@...nel.org, jiangshanlai@...il.com,
        akpm@...ux-foundation.org, mathieu.desnoyers@...icios.com,
        josh@...htriplett.org, tglx@...utronix.de, peterz@...radead.org,
        rostedt@...dmis.org, dhowells@...hat.com, edumazet@...gle.com,
        fweisbec@...il.com, oleg@...hat.com, joel@...lfernandes.org,
        Toke Høiland-Jørgensen <toke@...hat.com>
Subject: Re: [PATCH tip/core/rcu 3/4] rcu-tasks: Make ksoftirqd provide RCU
 Tasks quiescent states

On Thu, May 13, 2021 at 03:54:17PM +0900, Masami Hiramatsu wrote:
> Hi Paul,
> 
> On Wed, 12 May 2021 11:27:46 -0700
> "Paul E. McKenney" <paulmck@...nel.org> wrote:
> 
> > Heavy networking load can cause a CPU to execute continuously and
> > indefinitely within ksoftirqd, in which case there will be no voluntary
> > task switches and thus no RCU-tasks quiescent states.  This commit
> > therefore causes the exiting rcu_softirq_qs() to provide an RCU-tasks
> > quiescent state.
> > 
> > This of course means that __do_softirq() and its callers cannot be
> > invoked from within a tracing trampoline.
> 
> I would like to confirm that you mean "tracing trampoline" here is
> the code on the trampoline buffer, not the handler code which is
> invoked from the trampoline buffer but it is protected by preempt_disable(),
> am I understand correctly?

Maybe?  ;-)

If the handler code is invoked from the trampoline buffer, but
returns somewhere else, then it is OK for the handler code to invoke
__do_softirq() or its callers.

In addition, if the handler code is invoked from the trampoline buffer is
guaranteed never to be running in the context of the ksoftirqd kthread,
then it is also OK for the handler code to invoke __do_softirq() or
its callers.

Otherwise, if the handler code might return back into the trampoline
buffer and if that code might be running in the context of the ksoftirqd
kthread, invoking __do_softirq() or one of its callers could result in
the trampoline buffer no longer being there when it was returned to.

							Thanx, Paul

> Thank you,
> 
> > 
> > Reported-by: Toke Høiland-Jørgensen <toke@...hat.com>
> > Tested-by: Toke Høiland-Jørgensen <toke@...hat.com>
> > Signed-off-by: Paul E. McKenney <paulmck@...nel.org>
> > Cc: Steven Rostedt <rostedt@...dmis.org>
> > Cc: Masami Hiramatsu <mhiramat@...nel.org>
> > ---
> >  kernel/rcu/tree.c | 1 +
> >  1 file changed, 1 insertion(+)
> > 
> > diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
> > index 8e78b2430c16..f4daa4e60b14 100644
> > --- a/kernel/rcu/tree.c
> > +++ b/kernel/rcu/tree.c
> > @@ -242,6 +242,7 @@ void rcu_softirq_qs(void)
> >  {
> >  	rcu_qs();
> >  	rcu_preempt_deferred_qs(current);
> > +	rcu_tasks_qs(current, false);
> >  }
> >  
> >  /*
> > -- 
> > 2.31.1.189.g2e36527f23
> > 
> 
> 
> -- 
> Masami Hiramatsu <mhiramat@...nel.org>