linux-kernel - Re: [PATCH 16/23] sched,watchdog: Convert to sched_set

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: <20250516124250.GD16434@noisy.programming.kicks-ass.net>
Date: Fri, 16 May 2025 14:42:50 +0200
From: Peter Zijlstra <peterz@...radead.org>
To: Christophe Leroy <christophe.leroy@...roup.eu>
Cc: Steven Rostedt <rostedt@...dmis.org>, mingo@...nel.org,
	linux-kernel@...r.kernel.org, tglx@...utronix.de,
	qais.yousef@....com, juri.lelli@...hat.com,
	vincent.guittot@...aro.org, dietmar.eggemann@....com,
	bsegall@...gle.com, mgorman@...e.de, wim@...ux-watchdog.org,
	PRAT Maximilien <maximilien.prat@...soprasteria.com>,
	CASAUBON Jean Michel <jean-michel.casaubon@...soprasteria.com>
Subject: Re: [PATCH 16/23] sched,watchdog: Convert to sched_set_fifo()

On Fri, May 16, 2025 at 10:42:47AM +0200, Christophe Leroy wrote:
> Hi Peter,
> 
> Le 22/04/2020 à 15:24, Peter Zijlstra a écrit :
> > On Wed, Apr 22, 2020 at 08:51:55AM -0400, Steven Rostedt wrote:
> > > On Wed, 22 Apr 2020 13:27:35 +0200
> > > Peter Zijlstra <peterz@...radead.org> wrote:
> > > 
> > > > Because SCHED_FIFO is a broken scheduler model (see previous patches)
> > > > take away the priority field, the kernel can't possibly make an
> > > > informed decision.
> > > > 
> > > > Effectively changes prio from 99 to 50.
> > > 
> > > Hmm, this being a watchdog, and looking at commit 38a1222ae4f364d
> > > ("watchdog: core: make sure the watchdog worker always works")
> > > 
> > > I wonder if we should add a sched_set_high(), or have some other kind of
> > > watchdog handler that is guaranteed to trigger.
> > 
> > It's FIFO, it'll never win from either a deadline or a stop-task. After
> > that it doesn't matter.
> 
> It does matter. I didn't realise it when you sent out this patch five years
> ago, but today I'm facing an issue due to that patch. On powerpc 8xx the
> watchdog must be woken up every second, the HW is not able to take a higher
> timeout. I have process that is running at SCHED_FIFO prio 90. From time to
> time it keeps running for a bit more than one second, leading to a watchdog
> reset. This didn't happen before your patch.
> 
> Why having arbitrary selected prio 50 and not kept it at the highest
> possible priority ?

Because if your random program of choice would have had a prio-90 task
that was super duper more important -- like stopping the saw from taking
off your fingers that had a runtime of mere milliseconds, then having
the watchdog thread delay that could be catastrophic, no?

> What would be the solution to fix this unexpected watchdog reset ?
> 
> > 
> > fifo_high() is most definitely a bad idea, because then we're back into
> > the whole 'fifo priority' has meaning -- it does not. At least, it
> > doesn't until you've got system design information.
> 
> I don't understand why it has no meaning. When I have a user app at FIFO
> prio 90 and one at FIFO 89 I know the one at 90 will immediatly preempt the
> one at 89 when receiving data, and that's the behaviour I expect. What am I
> missing here ?

The 'until you've got system design information' bit. Not until you have
the domain expertise of all possible runnable tasks on your system, can
you determine FIFO priorities.

The thing is; you cannot design two programs that use FIFO in isolation
and blindly smash them together and expect it to work. FIFO is
fundamentally non-composable.

Someone has to go and set the priority of every FIFO task on the system,
otherwise things will not work. This very much includes the watchdog
thread.

So the solution is to know your setup and do your setup, including
the watchdog thread priority.