linux-kernel - Re: [PATCH v3 12/13] rv: Add deadline monitors

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: <87y0mr9vaw.fsf@yellow.woof>
Date: Thu, 25 Dec 2025 08:58:31 +0700
From: Nam Cao <namcao@...utronix.de>
To: Gabriele Monaco <gmonaco@...hat.com>, linux-kernel@...r.kernel.org,
 Steven Rostedt <rostedt@...dmis.org>, Gabriele Monaco
 <gmonaco@...hat.com>, Jonathan Corbet <corbet@....net>, Masami Hiramatsu
 <mhiramat@...nel.org>, linux-trace-kernel@...r.kernel.org,
 linux-doc@...r.kernel.org
Cc: Tomas Glozar <tglozar@...hat.com>, Juri Lelli <jlelli@...hat.com>, Clark
 Williams <williams@...hat.com>, John Kacur <jkacur@...hat.com>
Subject: Re: [PATCH v3 12/13] rv: Add deadline monitors

Nam Cao <namcao@...utronix.de> writes:
> Gabriele Monaco <gmonaco@...hat.com> writes:
>> Add the deadline monitors collection to validate the deadline scheduler,
>> both for deadline tasks and servers.
>>
>> The currently implemented monitors are:
>> * throttle:
>>     validate dl entities are throttled when they use up their runtime
>> * nomiss:
>>     validate dl entities run to completion before their deadiline
>>
>> Signed-off-by: Gabriele Monaco <gmonaco@...hat.com>
>
> There are some helper functions that I am a bit uncomfortable with
> (e.g. pi_of, is_dl_boosted, dl_is_implicit, ...) because they are
> relying on implementation details of deadline scheduler which can be
> changed. So ideally this patch should have an Ack from the scheduler people.

Think about this again, perhaps we should move all these helpers to
include/linux/sched/deadline.h instead? The scheduler people must be
aware of these functions, and maintain them. I don't want a situation
where the scheduler people make changes, and something else (which they
do not know exist) breaks.

Ideally, non-scheduler code should not look at private fields of
scheduler's structs.

Nam