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: <aQjV+Q25+O/8DpBS@e133380.arm.com>
Date: Mon, 3 Nov 2025 16:19:05 +0000
From: Dave Martin <Dave.Martin@....com>
To: Aaron Tomlin <atomlin@...mlin.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

Hi,

On Fri, Oct 31, 2025 at 05:25:41PM -0400, Aaron Tomlin wrote:
> On Fri, Oct 31, 2025 at 07:03:15PM +0000, Luck, Tony wrote:
> > 1) You'd also need to change the "write" path for the schemata file
> > (treating the CPU list as read-only).
> > 
> > 2) This would break user ABI, so is not going to happen.
> 
> Hi Tony,
> 
> Thank you for following up.
> 
> If I understand correctly, parse_cbm() and parse_bw() would return -EINVAL
> if the user incorrectly included the CPU list, no?
> 
> I suspect the issue is if one can read something from a file, one should be
> able to write the same thing back and have it either succeed or process
> only the valid parts. I agree maintaining ABI compatibility while allowing
> the new verbose output on the read path is not ideal.

Partly, but existing software that reads the file is also likely to get
confused by the new syntax appearing when reading the file.

(Nothing requires the data read out from the file to resemble what is
written in, though it certainly less surprising for userspace if it
looks the same, and if the data read will be accepted, with the same
meaning, when written back in.)


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.

On my system:

$ cat /sys/devices/system/cpu/cpu0/cache/index3/shared_cpu_list
-->
0-15,32-47

> > Users can see the association between the domain numbers and
> > CPUs in sysfs.
> > 
> > $ cat /sys/devices/system/cpu/cpu0/cache/index3/id
> > 0
> > $ cat /sys/devices/system/cpu/cpu0/cache/index3/shared_cpu_list
> > 0-27
> > 
> > Maybe not as convenient as a direct read-out in the schemata file.
> > But the information is easily accessible.
> 
> No, using the above to establish the association is absolutely fine. 

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.

Cheers
---Dave