linux-kernel - Re: [PATCH -next v2 3/4] rcu/nocb: Add warning to detect if overload advancement is ever useful

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: <aWq-1IXhOeisfKC3@pavilion.home>
Date: Fri, 16 Jan 2026 23:42:28 +0100
From: Frederic Weisbecker <frederic@...nel.org>
To: Joel Fernandes <joelagnelf@...dia.com>
Cc: linux-kernel@...r.kernel.org, "Paul E . McKenney" <paulmck@...nel.org>,
	Boqun Feng <boqun.feng@...il.com>, rcu@...r.kernel.org,
	Neeraj Upadhyay <neeraj.upadhyay@...nel.org>,
	Josh Triplett <josh@...htriplett.org>,
	Uladzislau Rezki <urezki@...il.com>,
	Steven Rostedt <rostedt@...dmis.org>,
	Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
	Lai Jiangshan <jiangshanlai@...il.com>,
	Zqiang <qiang.zhang@...ux.dev>
Subject: Re: [PATCH -next v2 3/4] rcu/nocb: Add warning to detect if overload
 advancement is ever useful

Le Wed, Jan 14, 2026 at 12:31:53PM -0500, Joel Fernandes a écrit :
> During callback overload, the NOCB code attempts an opportunistic
> advancement via rcu_advance_cbs_nowake().
> 
> Analysis via tracing with 300,000 callbacks flooded shows this
> optimization is likely dead code:
> - 30 overload conditions triggered
> - 0 advancements actually occurred
> - 100% of time no advancement due to current GP not done.
> 
> I also ran TREE05 and TREE08 for 2 hours and cannot trigger it.
> 
> When callbacks overflow (exceed qhimark), they are waiting for a grace
> period that hasn't completed yet. The optimization requires the GP to be
> complete to advance callbacks, but the overload condition itself is
> caused by callbacks piling up faster than GPs can complete. This creates
> a logical contradiction where the advancement cannot happen.
> 
> In *theory* this might be possible, the GP completed just in the nick of
> time as we hit the overload, but this is just so rare that it can be
> considered impossible when we cannot even hit it with synthetic callback
> flooding even, it is a waste of cycles to even try to advance, let alone
> be useful and is a maintenance burden complexity we don't need.

Rare is far from impossible with billions of android devices living out there.

I can imagine the warning to just hit if the flooding callback enqueuer happen
to hit the qhimark right after the GP has completed but before nocb_gp_wait()
managed yet to advance the callbacks.

But what would that prove then?

> 
> I suggest deletion. However, add a WARN_ON_ONCE for a merge window or 2
> and delete it after out of extreme caution.

2 merge windows is the least of time for that warning to ever land on the billions
machines. My phone still runs a v5.4 kernel :-)

And the patch doesn't quite qualify for a stable backport.

Anyway, consider an unpleasant case where nocb_gp_wait() is starving for
example. How would just advancing the callbacks help? We still need
nocb_gp_wait() to run its round to eventually wake up nocb_cb_wait()
so that the done callbacks are executed. And before doing that, it needs
to advance the callbacks anyway...

I'm personally in favour of removing this right away instead, unless Paul
has a good reason that I missed?

Thanks.

-- 
Frederic Weisbecker
SUSE Labs