linux-kernel - Re: [RFC PATCH v1] sched/uclamp: Introduce SCHED_FLAG_RESET_UCLAMP_ON

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

Message-ID: <20230428115755.7uklfd4fmpoee4dp@airbuntu>
Date:   Fri, 28 Apr 2023 12:57:55 +0100
From:   Qais Yousef <qyousef@...alina.io>
To:     David Dai <davidai@...gle.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>,
        Daniel Bristot de Oliveira <bristot@...hat.com>,
        Valentin Schneider <vschneid@...hat.com>,
        Qais Yousef <qyousef@...gle.com>,
        Quentin Perret <qperret@...gle.com>,
        Saravana Kannan <saravanak@...gle.com>,
        kernel-team@...roid.com, linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH v1] sched/uclamp: Introduce
 SCHED_FLAG_RESET_UCLAMP_ON_FORK flag

On 04/19/23 18:54, Qais Yousef wrote:

[...]

> I was considering to have something a bit more generic that allows selecting
> which attributes to reset.
> 
> For example a syscall with SCHED_FLAG_RESET_ON_FORK_SEL combined with
> SCHED_FLAG_UCLAMP_MIN/MAX will only reset those. This should make it extensible
> if we have other similar use cases in the future. The downside it *might*
> require to be done in a separate syscall to the one that sets these parameter.
> But it should be done once.
> 
> Maybe there's a better interface, but I think it makes sense to do it in a way
> that we won't have to do this again. Would be good to hear from maintainers
> first before you take my word for it ;-)

Actually I think we can do a better and simpler generic interface. We don't
need a new flag. We can just add a new parameter for what to reset on fork.
When this value is 0 (which it should be by default), it means reset
everything.

// pseudo code

#define RESET_ON_FORK_ALL	0
#define RESET_ON_FORK_POLICY	BIT(1) // implies resetting priority
#define RESET_ON_FORK_PRIORITY	BIT(2)
#define RESET_ON_FORK_UCLAMP	BIT(3)

struct sched_attr {
	...
	__u64 sched_reset_on_fork_flags;
};


Cheers

--
Qais Yousef