Re: [PATCH v7 31/49] x86/resctrl: Remove the limit on the number of CLOSID

[Reinette Chatre]

Hi James,

On 2/28/25 11:58 AM, James Morse wrote:
> From: Amit Singh Tomar <amitsinght@xxxxxxxxxxx>
> 
> Resctrl allocates and finds free CLOSID values using the bits of a u32.
> This restricts the number of control groups that can be created by
> user-space.
> 
> MPAM has an architectural limit of 2^16 CLOSID values, Intel x86 could
> be extended beyond 32 values. There is at least one MPAM platform which
> supports more than 32 CLOSID values.
> 
> Replace the fixed size bitmap with calls to the bitmap API to allocate
> an array of a sufficient size.
> 
> ffs() returns '1' for bit 0, hence the existing code subtracts 1 from
> the index to get the CLOSID value. find_first_bit() returns the bit
> number which does not need adjusting.
> 
> Signed-off-by: Amit Singh Tomar <amitsinght@xxxxxxxxxxx>
> [ morse: fixed the off-by-one in the allocator and the wrong
>  not-found value. Removed the limit. Rephrase the commit message. ]
> Signed-off-by: James Morse <james.morse@xxxxxxx>

...

> @@ -3071,6 +3085,7 @@ static void rdt_kill_sb(struct super_block *sb)
>  		resctrl_arch_disable_alloc();
>  	if (resctrl_arch_mon_capable())
>  		resctrl_arch_disable_mon();
> +	closid_exit();
>  	resctrl_mounted = false;
>  	kernfs_kill_sb(sb);
>  	mutex_unlock(&rdtgroup_mutex);

Above is the new change in this patch ... I am trying to understand the choice
in ordering since I expect that freeing resources is done in opposite
order from what it was allocated. I thus expected it to be before
schemata_list_destroy() but it is instead done as the last thing before removing
the superblock.

The changelog does not mention dependencies that need to be kept in mind.
I thought that there may be something going on with open files ... for
example if user kept "bit_usage" (that calls closid_allocated() that
depends on the closid_free_map) but a quick test confirmed that
if a file is open then an attempt to unmount will get a resource
busy error. So rdt_kill_sb() will not even start while a file is open.
Specifically, user sees a "umount: /sys/fs/resctrl: target is busy"

What am I missing?

Reinette