linux-kernel - Re: [PATCH v6.12] sched/fair: Block delayed tasks on throttled hierarchy during dequeue

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] [day] [month] [year] [list]

Message-ID: <20251015082216.GP4067720@noisy.programming.kicks-ass.net>
Date: Wed, 15 Oct 2025 10:22:16 +0200
From: Peter Zijlstra <peterz@...radead.org>
To: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc: K Prateek Nayak <kprateek.nayak@....com>,
	Sasha Levin <sashal@...nel.org>, stable@...r.kernel.org,
	Matt Fleming <matt@...dmodwrite.com>,
	Ingo Molnar <mingo@...hat.com>, Juri Lelli <juri.lelli@...hat.com>,
	Vincent Guittot <vincent.guittot@...aro.org>,
	linux-kernel@...r.kernel.org,
	Dietmar Eggemann <dietmar.eggemann@....com>,
	Steven Rostedt <rostedt@...dmis.org>,
	Ben Segall <bsegall@...gle.com>, Mel Gorman <mgorman@...e.de>,
	Valentin Schneider <vschneid@...hat.com>,
	kernel-team@...udflare.com, Matt Fleming <mfleming@...udflare.com>,
	Oleg Nesterov <oleg@...hat.com>, John Stultz <jstultz@...gle.com>,
	Chris Arges <carges@...udflare.com>
Subject: Re: [PATCH v6.12] sched/fair: Block delayed tasks on throttled
 hierarchy during dequeue

On Wed, Oct 15, 2025 at 09:27:53AM +0200, Greg Kroah-Hartman wrote:
> On Wed, Oct 15, 2025 at 11:57:19AM +0530, K Prateek Nayak wrote:
> > Hello Greg,
> > 
> > On 10/15/2025 11:44 AM, Greg Kroah-Hartman wrote:
> > >> Greg, Sasha,
> > >>
> > >> This fix cleanly applies on top of v6.16.y and v6.17.y stable kernels
> > >> too when cherry-picked from v6.12.y branch (or with 'git am -3'). Let me
> > >> know if you would like me to send a seperate patch for each.
> > >>
> > >> As mentioned above, the upstream fixes this as a part of larger feature
> > >> and we would only like these bits backported. If there are any future
> > >> conflicts in this area during backporting, I would be more than happy to
> > >> help out resolve them.
> > > 
> > > Why not just backport all of the mainline changes instead?  As I say a
> > > lot, whenever we do these "one off" changes, it's almost always wrong
> > > and causes problems over the years going forward as other changes around
> > > the same area can not be backported either.
> > > 
> > > So please, try to just backport the original commits.
> > 
> > Peter was in favor of backporting just the necessary bits in
> > https://lore.kernel.org/all/20250929103836.GK3419281@noisy.programming.kicks-ass.net/
> > 
> > Backporting the whole of per-task throttle feature is lot more heavy
> > handed with the core changes adding:
> > 
> >  include/linux/sched.h |   5 +
> >  kernel/sched/core.c   |   3 +
> >  kernel/sched/fair.c   | 451 ++++++++++++++++++++++++------------------
> >  kernel/sched/pelt.h   |   4 +-
> >  kernel/sched/sched.h  |   7 +-
> >  5 files changed, 274 insertions(+), 196 deletions(-)
> 
> That's very tiny overall in the scheme of what we take for the stable
> trees.
> 
> > And a few more fixes that will add to the above before v6.18. I'll defer
> > to Peter to decide the best course of action.
> 
> We'll defer to the maintainers of the subsystem as to what they want
> here.  If they say take this smaller patch, we'll be glad to do so.

So if the timing of all this would've been slightly different, I'd have
taken the smaller patch and routed it through sched/urgent in time for
the 6.17 release. And we'd not have had this discussion, but alas.

Also, while we're fairly confident in the task throttling rework, it is
somewhat invasive and hasn't seen widespread testing -- it is
conceivable there are performance issues.

So at this point I would really rather backport the smaller patch that
fixes the immediate bug.

Thanks!