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

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: <6f2886fa-a563-43e0-b2c5-5de068c41863@arm.com>
Date: Mon, 10 Mar 2025 14:20:58 +0000
From: James Morse <james.morse@....com>
To: Reinette Chatre <reinette.chatre@...el.com>, x86@...nel.org,
 linux-kernel@...r.kernel.org
Cc: Thomas Gleixner <tglx@...utronix.de>, Ingo Molnar <mingo@...hat.com>,
 Borislav Petkov <bp@...en8.de>, H Peter Anvin <hpa@...or.com>,
 Babu Moger <Babu.Moger@....com>, shameerali.kolothum.thodi@...wei.com,
 D Scott Phillips OS <scott@...amperecomputing.com>,
 carl@...amperecomputing.com, lcherian@...vell.com,
 bobo.shaobowang@...wei.com, tan.shaopeng@...itsu.com,
 baolin.wang@...ux.alibaba.com, Jamie Iles <quic_jiles@...cinc.com>,
 Xin Hao <xhao@...ux.alibaba.com>, peternewman@...gle.com,
 dfustini@...libre.com, amitsinght@...vell.com,
 David Hildenbrand <david@...hat.com>, Rex Nie <rex.nie@...uarmicro.com>,
 Dave Martin <dave.martin@....com>, Koba Ko <kobak@...dia.com>,
 Shanker Donthineni <sdonthineni@...dia.com>, fenghuay@...dia.com
Subject: Re: [PATCH v7 31/49] x86/resctrl: Remove the limit on the number of
 CLOSID

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@...vell.com>
>>
>> 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