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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <765e80ba6895985aadafc5c1bfe8a361575252f2.camel@redhat.com>
Date: Mon, 29 Dec 2025 08:00:44 +0100
From: Gabriele Monaco <gmonaco@...hat.com>
To: Nam Cao <namcao@...utronix.de>, linux-kernel@...r.kernel.org, Steven
 Rostedt <rostedt@...dmis.org>, Masami Hiramatsu <mhiramat@...nel.org>, 
	linux-trace-kernel@...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

On Thu, 2025-12-25 at 08:58 +0700, Nam Cao wrote:
> Nam Cao <namcao@...utronix.de> writes:
> > 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.

Thanks for the review!
I'm going to ping scheduler guys some time after the holidays.

> 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.

That's a fair point, I just copied those functions from kernel/sched/deadline.c
but that's dirty indeed.
Going to try exporting them to deadline.h and see if no one complains.

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

Yeah, one may argue those modules shouldn't be doing what they're doing with the
deadline entities. To be fair those modules are quite dependant on the data
structure implementation, but the alternative would be to maintain a set of
getter functions which might as well break.
Or at least I don't see a better way.

Thanks,
Gabriele