linux-kernel - Re: [PATCH] sched_ext: Provides a sysfs 'events' to expose core event counters

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: <Z64hrU6P67pUA5o9@slm.duckdns.org>
Date: Thu, 13 Feb 2025 06:45:33 -1000
From: Tejun Heo <tj@...nel.org>
To: Changwoo Min <changwoo@...lia.com>
Cc: void@...ifault.com, arighi@...dia.com, kernel-dev@...lia.com,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] sched_ext: Provides a sysfs 'events' to expose core
 event counters

Hello, sorry about the late reply.

On Tue, Feb 11, 2025 at 09:57:08AM +0900, Changwoo Min wrote:
> > This probably should belong to the root/ subdir as we'd probably want to
> > keep the event counter separate per scheduler instance in the
> > multi-scheduler future.
> 
> I feel this is a bit contradictory to the need to access the core
> event counters even after an scx scheduler is unloaded. In the
> current implementation, root/ subdir appears and disappears when
> an scx scheduler is loaded and unloaded.
> 
> We may change the scx_ktype to something similar to
> scx_global_attr_group in order to keep root/ subdir. We then show
> an empty file for root/ops when no scx scheduler is loaded while
> keep the root/events file intact. I am not sure if this is what
> we want.
> 
> What do you think?

Hmm... I don't think we can keep the directory for counters of schedulers
that have been unloaded. Looks like the right thing to do is giving up on
the idea of being able to access the counters after the scheduler is
unloaded. The counters are dumped on error exits, so hopefully this isn't
too big a loss. What do you think?

Thanks.

-- 
tejun