linux-kernel - Re: [PATCH -next v3 2/3] rcu/nocb: Remove dead callback overload handling

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: <1737646200.reply.joelagnelf@nvidia.com>
Date: Thu, 23 Jan 2026 10:30:00 -0500
From: Joel Fernandes <joelagnelf@...dia.com>
To: "Paul E. McKenney" <paulmck@...nel.org>
Cc: linux-kernel@...r.kernel.org,
	Boqun Feng <boqun.feng@...il.com>,
	rcu@...r.kernel.org,
	Frederic Weisbecker <frederic@...nel.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 v3 2/3] rcu/nocb: Remove dead callback overload handling

On Thu, Jan 22, 2026 at 09:46:58PM -0800, Paul E. McKenney wrote:
> > Thanks. I will focus on this argument, then. I will resend with a better
> > patch description in the morning.
> 
> And my Reviewed-by does assume that change, so go ahead and send the
> improved commit log with my Reviewed-by appended.

Sure, will do.

> > Hmm true. There is also the case that any of the kthreads in the way of the
> > callback getting preempted by the hypervisor could also be problematic, to
> > your point of requiring a more principled approach. I guess we did not want
> > the reader side vCPU preemption workarounds either for similar reason.
> 
> Well, principles only get you so far.  We need both the principles and the
> pragmatism to know when to depart from those principles when warranted.

Agreed. Indeed we have to balance the cost of workarounds and in the case
of per cpu blocked lists, I agree that perhaps the balance tipped more in
favor of not doing it pending other more comprehensive fixes.

> > One trick I found irrespective of virtualization, is, rcu_nocb_poll can
> > result in grace periods completing faster. I think this could help overload
> > situations by retiring callbacks sooner than later. I can experiment with
> > this idea in future. Was considering a dynamic trigger to enable polling
> > mode in overload. I guess there is one way to find out how well this will
> > work, but initial testing does look promising. :-D.
> 
> Careful of the effect on power consumption, especially for the world of
> battery-powered embedded systems!  ;-)

Thanks, yes I was considering this argument already to be honest as one of
the potential pitfalls, but thanks for the reminder! FWIW, my inclination
is that if we are in an overloaded situation, we would not benefit from
idleness anyway. To the contrary, I think we may hurt idleness and power
if we are not able to settle the system into a quiet state due to slowness
in alleviating the callback overload. I will profile for CPU consumption
and maybe run turbostat to check whenever I have the prototype.

-- 
Joel Fernandes