linux-kernel - Re: [PATCH 08/11] rcu/nocb: Limit number of softirq callbacks only on softirq

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]

Date:   Fri, 01 Oct 2021 18:51:08 +0100
From:   Valentin Schneider <valentin.schneider@....com>
To:     Frederic Weisbecker <frederic@...nel.org>,
        "Paul E . McKenney" <paulmck@...nel.org>
Cc:     LKML <linux-kernel@...r.kernel.org>,
        Frederic Weisbecker <frederic@...nel.org>,
        Sebastian Andrzej Siewior <bigeasy@...utronix.de>,
        Peter Zijlstra <peterz@...radead.org>,
        Uladzislau Rezki <urezki@...il.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        Boqun Feng <boqun.feng@...il.com>,
        Neeraj Upadhyay <neeraju@...eaurora.org>,
        Josh Triplett <josh@...htriplett.org>,
        Joel Fernandes <joel@...lfernandes.org>, rcu@...r.kernel.org
Subject: Re: [PATCH 08/11] rcu/nocb: Limit number of softirq callbacks only on softirq

On 30/09/21 00:10, Frederic Weisbecker wrote:
> The current condition to limit the number of callbacks executed in a
> row checks the offloaded state of the rdp. Not only is it volatile
> but it is also misleading: the rcu_core() may well be executing
> callbacks concurrently with NOCB kthreads, and the offloaded state
> would then be verified on both cases. As a result the limit would
> spuriously not apply anymore on softirq while in the middle of
> (de-)offloading process.
>
> Another issue with the condition is that rcu_is_callbacks_kthread()
> doesn't check if we are actually running callbacks from rcuc itself or
> from a softirq interrupting rcuc.
>

Doesn't rcutree.use_softirq imply rcuc is never woken, in which case
RCU_SOFTIRQ can't interrupt rcuc (e.g. while run atop an IRQ exit)?
I suppose during the (de)offload sequence we could have RCU_SOFTIRQ running
atop the NOCB CB kthread, but that's not something
rcu_is_callbacks_kthread() detects.

Also, why is rcu_is_callbacks_kthread() hardcoded to false for
!CONFIG_RCU_BOOST? Isn't it relevant for do_rcu_batch() ratelimiting
regardless (at least before your patches)?