linux-kernel - Re: [PATCH v10 07/30] x86/resctrl: Check all domains are offline in resctrl

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: <25dcc566-08db-466a-853c-4c5f3ddad531@arm.com>
Date: Tue, 13 May 2025 17:42:45 +0100
From: James Morse <james.morse@....com>
To: Reinette Chatre <reinette.chatre@...el.com>,
 Catalin Marinas <catalin.marinas@....com>
Cc: x86@...nel.org, linux-kernel@...r.kernel.org,
 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,
 Shaopeng Tan <tan.shaopeng@...fujitsu.com>
Subject: Re: [PATCH v10 07/30] x86/resctrl: Check all domains are offline in
 resctrl_exit()

Hi Reinette,

On 09/05/2025 17:28, Reinette Chatre wrote:
> On 5/9/25 9:17 AM, Reinette Chatre wrote:
>> On 5/9/25 4:21 AM, Catalin Marinas wrote:
>>> On Thu, May 08, 2025 at 10:51:23AM -0700, Reinette Chatre wrote:
>>>> On 5/8/25 10:18 AM, James Morse wrote:
>>>>> diff --git a/arch/x86/kernel/cpu/resctrl/rdtgroup.c b/arch/x86/kernel/cpu/resctrl/rdtgroup.c
>>>>> index 88197afbbb8a..f617ac97758b 100644
>>>>> --- a/arch/x86/kernel/cpu/resctrl/rdtgroup.c
>>>>> +++ b/arch/x86/kernel/cpu/resctrl/rdtgroup.c
>>>>> @@ -4420,8 +4420,32 @@ int __init resctrl_init(void)
>>>>>  	return ret;
>>>>>  }
>>>>>  
>>>>> +static bool __exit resctrl_online_domains_exist(void)
>>>>> +{
>>>>> +	struct rdt_resource *r;
>>>>> +
>>>>> +	for_each_rdt_resource(r) {
>>>>> +		if (!list_empty(&r->ctrl_domains) || !list_empty(&r->mon_domains))
>>>>> +			return true;
>>>>> +	}
>>>>> +
>>>>> +	return false;
>>>>> +}
>>>>
>>>> This looks the same as before. Did you notice my comment in [1] about this list_empty() usage?
>>>
>>> James may have missed that comment (and he's off today). Copying your
>>> comment here:
>>>
>>>> A list needs to be initialized for list_empty() to behave as intended. A list within
>>>> an uninitialized or "kzalloc()'ed" struct will not be considered empty.
>>>> resctrl_arch_get_resource() as used by for_each_rdt_resource() already establishes
>>>> that if an architecture does not support a particular resource then it can (should?)
>>>> return a "dummy/not-capable" resource. I do not think resctrl should require
>>>> anything additionally like initializing the lists of a dummy/not-capable resource
>>>> to support things like this loop.
>>>
>>> I agree the description of the resctrl_arch_get_resource() semantics
>>> doesn't specifically mention that the list_heads should be initialised
>>> in dummy resources. IIUC, x86 should be safe for now since the
>>> rdt_resources_all[] array elements have the ctrl_domains and mon_domains
>>> list_heads initialised.

I had missed this. The logic makes sense - I'll spin this as a v11.


>> Not all x86 resources support both control and monitoring. For these resources x86
>> only initializes the arrays it uses. For example, the L2 resource only supports control
>> and thus only the ctrl_domains list is initialized. When the above loop runs on a resource
>> like this it will return "true" because it believes there are monitoring domains
>> online.
>>
>> Your conclusion that x86 is safe for now may (reason for use of "may" follows) still
>> be valid since resctrl_online_domains_exist() is only called by x86 from its
>> resctrl_arch_exit() that is within the "exit.text" section. Here is where I am not
>> entirely certain of the impact (hence the earlier use of "may") since from what I can
>> tell the linker does not actually discard "exit.text" on x86 because it defines
>> RUNTIME_DISCARD_EXIT.

Aha - I'd not spotted that one before.


> If you are not familiar with the details then I should add for completeness that resctrl
> is not currently capable of being compiled as a module.


Thanks,

James