linux-kernel - Re: [PATCH 0/1] fs/resctrl: Show domain CPU list in schema output

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: <6ianowe727m2mhytn4gsthj2pwbkpxmojtktka6p4wnzajm6rd@b5lcez7kjlec>
Date: Wed, 5 Nov 2025 23:41:04 -0500
From: Aaron Tomlin <atomlin@...mlin.com>
To: Dave Martin <Dave.Martin@....com>
Cc: "Luck, Tony" <tony.luck@...el.com>, 
	"Chatre, Reinette" <reinette.chatre@...el.com>, "james.morse@....com" <james.morse@....com>, 
	"babu.moger@....com" <babu.moger@....com>, "tglx@...utronix.de" <tglx@...utronix.de>, 
	"mingo@...hat.com" <mingo@...hat.com>, "bp@...en8.de" <bp@...en8.de>, 
	"dave.hansen@...ux.intel.com" <dave.hansen@...ux.intel.com>, "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 0/1] fs/resctrl: Show domain CPU list in schema output

On Mon, Nov 03, 2025 at 04:19:05PM +0000, Dave Martin wrote:
> Partly, but existing software that reads the file is also likely to get
> confused by the new syntax appearing when reading the file.

Hi Dave,

Thank you for your feedback.

I agree.

> Note, using a comma as a delimiter may be problematic with %pbl-style
> lists, since if the list is discontiguous then the pretty-printed list
> can contain commas too.

Fair point.

> In theory, a alternate write syntax could be supported without
> breaking compatibility, say:
> 
> 	cpu<n>=<mask>
> 
> instead of
> 
> 	<domain>=<main>
> 
> as a alternative way of referring to the control domain containing
> CPU <n>.
> 
> But I think that this may do as much harm as good -- if the user
> doesn't understand the topology, trying to program the masks on a per-
> CPU basis isn't going to work do what the user wants anyway.
> 
> So I think we'd want a good argument as to why this is needed / useful.

Understood. What Tony mentioned previously is sufficient; I should have
reviewed drivers/base/cacheinfo.c before posting.


Kind regards,
-- 
Aaron Tomlin