linux-kernel - Re: [PATCH] sched_ext: Provide a sysfs enable

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: <20240923165749.GB313849@pauld.westford.csb>
Date: Mon, 23 Sep 2024 12:57:49 -0400
From: Phil Auld <pauld@...hat.com>
To: Tejun Heo <tj@...nel.org>
Cc: Andrea Righi <andrea.righi@...ux.dev>,
	David Vernet <void@...ifault.com>,
	Giovanni Gherdovich <giovanni.gherdovich@...e.com>,
	Kleber Sacilotto de Souza <kleber.souza@...onical.com>,
	Marcelo Henrique Cerri <marcelo.cerri@...onical.com>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] sched_ext: Provide a sysfs enable_seq counter

On Mon, Sep 23, 2024 at 06:47:12AM -1000 Tejun Heo wrote:
> Hello,
> 
> On Mon, Sep 23, 2024 at 06:34:20PM +0200, Andrea Righi wrote:
> ...
> > > > Yes, the load sequence number should stay persistent across all schedulers,
> > > > but each scheduler should report the sequence number at which *it* was
> > > > loaded. Note that this doesn't really change anything now. If you only care
> > > > whether any SCX scheduler has ever been loaded, you'd always look under
> > > > root.
> > > >
> > > 
> > > In my testing root is not there is nothing is loaded. 
> 
> Ah, right.
> 
> > Right, there's no root if no sched_ext scheduler is loaded. Maybe we
> > should always keep root present, or have a global counter and one
> > per-sched?
> 
> I'll apply as-is. Let's add per-scheduler load seq separately.

Thanks! I was thinking that per-scheduler you could just snapshot the
global counter (either before or after increment) on load. Then you
could easily tell when each was loaded relative to each other etc.

Especially while "per-scheduler" is defined by string comparison I'd
prefer not to rely on that for this use case. 


Cheers,
Phil

> 
> Thanks.
> 
> -- 
> tejun
> 

--