linux-kernel - Re: [PATCH v2] sched/deadline: Reset dl

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: <be763631-f677-4bad-8285-69dbfe29db54@redhat.com>
Date: Tue, 27 Jan 2026 16:00:31 +0000
From: Gabriele Monaco <gmonaco@...hat.com>
To: Andrea Righi <arighi@...dia.com>
Cc: Ingo Molnar <mingo@...hat.com>, Peter Zijlstra <peterz@...radead.org>,
	Juri Lelli <juri.lelli@...hat.com>,
	Vincent Guittot <vincent.guittot@...aro.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>, Tejun Heo <tj@...nel.org>,
	Joel Fernandes <joelagnelf@...dia.com>,
	David Vernet <void@...ifault.com>,
	Changwoo Min <changwoo@...lia.com>, Daniel Hodges <hodgesd@...a.com>,
	sched-ext@...ts.linux.dev, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2] sched/deadline: Reset dl_server execution state on
 stop

2026-01-27T14:18:29Z Andrea Righi <arighi@...dia.com>:
> I think my case should work also doing something like this (I'll run some
> tests later to double check):
>
>     if (dl_se->runtime <= 0)
>         dl_se->dl_defer_running = 0;
>
> In this way:
> - short sleep + remaining runtime > 0
>    - dl_defer_running stays set
>    - restart can go A->D directly
>    - no extra defer / zero-laxity penalty
>
> - stop with exhausted (or negative) runtime
>    - dl_defer_running is cleared
>    - restart must re-establish eligibility
>    - deferral / timer is armed again
>    - no stale "already running" server

Yeah that looks like the neatest to me.
Fair tasks are a bit more penalised than now but won't be if they really sleep before consuming the runtime, which I think was the whole point of this logic.

> However, I think the right assumption should be that both runtime **and**
> deadline are still coherent, so we should probably do something like this
> to be fully correct:
>
>     if (dl_se->runtime <= 0 ||
>         dl_time_before(dl_se->deadline, rq_clock(dl_se->rq)))
>         dl_se->dl_defer_running = 0;
>
> This makes the stop path slightly more complex, so I'm not sure whether
> it's preferable to go in this direction or just unconditionally clearing
> dl_defer_running, which is simpler and more explicit from a state-machine
> point of view.

I think it's trickier than that. The state machine is coherent as long as the the server is restarted after the deadline, no matter when it was stopped.

This check should probably be done at some point during dl_server_start().
But yeah it's probably an overkill.

Thanks,
Gabriele