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: <4whfbgq336xfuov4i4nwwrn35ywwlwizuvpdlstmdqzkhvwrq6@eits26xbwyz6>
Date: Fri, 7 Nov 2025 19:19:54 -0500
From: Aaron Tomlin <atomlin@...mlin.com>
To: "Moger, Babu" <bmoger@....com>
Cc: tony.luck@...el.com, reinette.chatre@...el.com, Dave.Martin@....com, 
	james.morse@....com, babu.moger@....com, tglx@...utronix.de, mingo@...hat.com, 
	bp@...en8.de, dave.hansen@...ux.intel.com, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/2] x86/resctrl: Add io_alloc_min_cbm_all interface for
 CBM reset

On Fri, Nov 07, 2025 at 05:08:03PM -0600, Moger, Babu wrote:
> No, I don’t agree with introducing this new interface.
> 
> These settings are intended to be modified only by system administrators,
> not general users.
> 
> Administrators are already expected to have complete knowledge of the
> hardware and corresponding configuration details. They also typically rely
> on benchmark data to determine appropriate settings.
> 
> Additionally, this approach is not consistent with our existing CBM setting
> model.

Hi Babu,

I fully appreciate your point that system administrators are expected to
have complete knowledge of the hardware configuration. I believe my initial
motivation may have been unclear, so let me clarify the intention behind
"io_alloc_min_cbm_all".

The intention of this new interface is not to hide lower-level details from
the administrator, but rather to simplify a specific, high-overhead
administration task and prevent human error, which I encountered during
testing of your series.



By default, it is my understanding that when I/O allocation CBM is enabled,
all applicable shared L3 resources typically have their CBM bits set (e.g.,
ffff). If an administrator wishes to revert to a clean baseline before
applying a subset of dedicated bits, the manual process requires them to
not only have knowledge of every single Domain ID
applicable to the shared L3 resource but manually construct a long,
error-prone input string.

The objective of "io_alloc_min_cbm_all" is to provide a quick and accurate
medium to revert this topology-dependent default configuration to the
minimal supported state, thereby avoiding possible miscalculation or
omission of a Domain ID in the CBM string. As shown in the usage flow
below, the new interface drastically reduces the complexity of setting up a
specific configuration:

# cat /sys/fs/resctrl/info/L3/io_alloc_cbm
0=ffff;2=ffff;4=ffff;6=ffff;8=ffff;10=ffff;12=ffff;14=ffff;16=ffff;18=ffff;20=ffff;22=ffff;24=ffff;26=ffff;28=ffff;30=ffff;32=ffff;34=ffff;36=ffff;38=ffff;40=ffff;42=ffff;44=ffff;46=ffff;48=ffff;50=ffff;52=ffff

# echo 0=0;2=0;4=0;6=4;8=4;10=0;12=0;14=0;16=ffff;18=ffff;20=0;22=0;24=0;26=0;28=0;30=0;32=0;34=4;36=0;38=0;40=0;42=0;44=0;46=0;48=0;50=0;52=0 > /sys/fs/resctrl/info/L3/io_alloc_cbm

# After (using the new interface):
# Administrator uses the new interface to clear all domains automatically:
echo 0 > /sys/fs/resctrl/info/L3/io_alloc_min_cbm_all

# Then applies only the specific, custom masks needed:
echo 6=4;8=4;16=ffff;18=ffff;34=4 > /sys/fs/resctrl/info/L3/io_alloc_cbm



In essence, the new file automates the clearing phase across the entire
topology, allowing the administrator to immediately proceed to the
customization phase with a much shorter, focused command.

I believe the efficiency and guaranteed correctness for this specific use
case justifies the addition. Please let me know if this clarifies the
motivation and if you have an alternative suggestion for achieving this
guaranteed full-topology reset.

If, after considering this clarification, you still feel this approach
should not be merged, I will certainly defer to your judgment and withdraw
the patch.



Kind regards,
-- 
Aaron Tomlin

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ