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: <357e2c84-7b60-4ad7-8511-a8415999174d@igalia.com>
Date: Fri, 14 Feb 2025 16:07:33 +0900
From: Changwoo Min <changwoo@...lia.com>
To: Tejun Heo <tj@...nel.org>
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 Tejun,


Thank you for the review!

On 25. 2. 14. 01:45, Tejun Heo wrote:
> 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?

Yes, dumping the event counters is a part of scx_dump_state().
I agree. That's a reasonable choice. I will move 'events' under
the root/ subdir and send out a new version.

Regards,
Changwoo Min

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ