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: <20210514024912.a38f755add13a0f1dc73395a@kernel.org>
Date:   Fri, 14 May 2021 02:49:12 +0900
From:   Masami Hiramatsu <mhiramat@...nel.org>
To:     paulmck@...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, 13 May 2021 07:21:10 -0700
"Paul E. McKenney" <paulmck@...nel.org> wrote:

> 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.

Hmm, the optprobe may be involved in this case. It always return to
the trampoline and handler does not disable irqs (only disable preempt).
BTW, what will call the __do_softirq()? Is hardirq safe?

Thank you,

-- 
Masami Hiramatsu <mhiramat@...nel.org>