linux-kernel - Re: [PATCH] fs/resctrl: Consider sparse masks when initializing new group's allocation

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: <aR9tbOMEVSDGvtoA@agluck-desk3>
Date: Thu, 20 Nov 2025 11:35:08 -0800
From: "Luck, Tony" <tony.luck@...el.com>
To: Reinette Chatre <reinette.chatre@...el.com>
CC: <james.morse@....com>, <Dave.Martin@....com>, <babu.moger@....com>,
	<bp@...en8.de>, <tglx@...utronix.de>, <dave.hansen@...ux.intel.com>,
	<x86@...nel.org>, <hpa@...or.com>, <fustini@...nel.org>,
	<fenghuay@...dia.com>, <peternewman@...gle.com>,
	<linux-kernel@...r.kernel.org>, <patches@...ts.linux.dev>,
	<christophe.jaillet@...adoo.fr>
Subject: Re: [PATCH] fs/resctrl: Consider sparse masks when initializing new
 group's allocation

On Mon, Nov 17, 2025 at 04:42:45PM -0800, Reinette Chatre wrote:
> A new resource group is intended to be created with sane defaults. For
> a cache resource this means all cache portions the new group could possibly
> allocate into. This includes unused cache portions and shareable cache
> portions used by other groups and hardware.
> 
> New resource group creation does not take sparse masks into account. After
> determining the bitmask reflecting the new group's possible allocations the
> bitmask is forced to be contiguous even if the system supports sparse masks.
> For example, a new group could by default allocate into a large portion of
> cache represented by 0xff0f, but it is instead created with a mask of 0xf.
> 
> Do not force a contiguous allocation range if the system supports sparse
> masks.

Note that the allocated mask on systems that require contiguous bit allocation
is not optimal. In your example where the available bits for the new group
are 0xff0f, resctrl will focus on the least significant contguous range and
set 0x000f, rather than the larger group of bits 0xff00.

Fixing this would be more complex, and I don't see a lot of value as the
user is very likley to rewrite the schemata immediatley after creating
the new group.

So for this patch as-is:

Reviewed-by: Tony Luck <tony.luck@...el.com>

> Signed-off-by: Reinette Chatre <reinette.chatre@...el.com>
> ---
> Not a stable candidate because nobody has complained about this and it is
> not a serious issue but instead an optimization. Discovered during code
> inspection as part of review of:
> https://lore.kernel.org/lkml/c5807e73e0f4068392036a867d24a8e21c200421.1761464280.git.christophe.jaillet@wanadoo.fr/
> 
> Tested on system that supports sparse masks.
> ---
>  fs/resctrl/rdtgroup.c | 7 ++++---
>  1 file changed, 4 insertions(+), 3 deletions(-)
> 
> diff --git a/fs/resctrl/rdtgroup.c b/fs/resctrl/rdtgroup.c
> index 0320360cd7a6..41ce4b377af4 100644
> --- a/fs/resctrl/rdtgroup.c
> +++ b/fs/resctrl/rdtgroup.c
> @@ -3383,11 +3383,12 @@ static u32 cbm_ensure_valid(u32 _val, struct rdt_resource *r)
>  {
>  	unsigned int cbm_len = r->cache.cbm_len;
>  	unsigned long first_bit, zero_bit;
> -	unsigned long val = _val;
> +	unsigned long val;
>  
> -	if (!val)
> -		return 0;
> +	if (!_val || r->cache.arch_has_sparse_bitmasks)
> +		return _val;
>  
> +	val = _val;
>  	first_bit = find_first_bit(&val, cbm_len);
>  	zero_bit = find_next_zero_bit(&val, cbm_len, first_bit);
>  
> -- 
> 2.50.1
>