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

[James Morse]

Hi Reinette,

On 07/03/2025 04:40, Reinette Chatre wrote:
> 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.

>> @@ -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?

I just shoved it at the end of the list, but before anything 'outside' resctrl.
I'll change it to be the opposite of the order in rdt_get_tree().


Thanks,

James