linux-kernel - Re: [PATCH v20 07/18] x86/resctrl: Block use of mba_MBps mount option on Sub-NUMA Cluster (SNC) systems

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <369f5ed6-603f-40b6-9c73-e2ee27bc7997@intel.com>
Date: Fri, 21 Jun 2024 10:10:03 -0700
From: Reinette Chatre <reinette.chatre@...el.com>
To: Tony Luck <tony.luck@...el.com>
CC: "Yu, Fenghua" <fenghua.yu@...el.com>, "Wieczor-Retman, Maciej"
	<maciej.wieczor-retman@...el.com>, Peter Newman <peternewman@...gle.com>,
	James Morse <james.morse@....com>, Babu Moger <babu.moger@....com>, "Drew
 Fustini" <dfustini@...libre.com>, Dave Martin <Dave.Martin@....com>,
	"x86@...nel.org" <x86@...nel.org>, "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>, "patches@...ts.linux.dev"
	<patches@...ts.linux.dev>
Subject: Re: [PATCH v20 07/18] x86/resctrl: Block use of mba_MBps mount option
 on Sub-NUMA Cluster (SNC) systems

Hi Tony,

On 6/21/24 8:24 AM, Tony Luck wrote:
> On Thu, Jun 20, 2024 at 06:56:56PM -0700, Reinette Chatre wrote:
>> On 6/20/24 3:07 PM, Luck, Tony wrote:
>>>>> When SNC is enabled there is a mismatch between the MBA control function
>>>>> which operates at L3 cache scope and the MBM monitor functions which
>>>>> measure memory bandwidth on each SNC node.
>>>>>
>>>>> Block use of the mba_MBps when scopes for MBA/MBM do not match.
>>>>>
>>>>> Signed-off-by: Tony Luck <tony.luck@...el.com>
>>>>> ---
>>>>>     arch/x86/kernel/cpu/resctrl/rdtgroup.c | 4 +++-
>>>>>     1 file changed, 3 insertions(+), 1 deletion(-)
>>>>>
>>>>> diff --git a/arch/x86/kernel/cpu/resctrl/rdtgroup.c b/arch/x86/kernel/cpu/resctrl/rdtgroup.c
>>>>> index eb3bbfa96d5a..a0a43dbe011b 100644
>>>>> --- a/arch/x86/kernel/cpu/resctrl/rdtgroup.c
>>>>> +++ b/arch/x86/kernel/cpu/resctrl/rdtgroup.c
>>>>> @@ -2339,10 +2339,12 @@ static void mba_sc_domain_destroy(struct rdt_resource *r,
>>>>>      */
>>>>>     static bool supports_mba_mbps(void)
>>>>>     {
>>>>> +   struct rdt_resource *rmbm = &rdt_resources_all[RDT_RESOURCE_L3].r_resctrl;
>>>>>       struct rdt_resource *r = &rdt_resources_all[RDT_RESOURCE_MBA].r_resctrl;
>>>>>
>>>>>       return (is_mbm_local_enabled() &&
>>>>> -           r->alloc_capable && is_mba_linear());
>>>>> +           r->alloc_capable && is_mba_linear() &&
>>>>> +           r->ctrl_scope == rmbm->mon_scope);
>>>>>     }
>>>>>
>>>>>     /*
>>>>
>>>> The function comments of supports_mba_mbps() needs an update to accompany
>>>> this new requirement.
>>>
>>> Will add comment on extra requirement.
>>>
>>>> I also think that the "mba_MBps" mount option is now complicated enough to
>>>> warrant a clear error to user space when using it fails. invalfc() is
>>>> available for this and enables user space to get detailed log message
>>>> from a read() on an fd created by fsopen().
>>>>
>>>> Perhaps something like (please check line length and feel free to improve
>>>> since as is it may quite cryptic):
>>>>         rdt_parse_param(...)
>>>>         {
>>>>
>>>>
>>>>         ...
>>>>         case Opt_mba_mbps:
>>>>                 if (!supports_mba_mbps())
>>>>                         return invalfc(fc, "mba_MBps requires both MBM and (linear scale) MBA at L3 scope");
>>>>         ...
>>>>         }
>>>
>>> Line length is indeed a problem (108 characters). Usual line split methods barely help as the moving the
>>> string to the next line and aligning with the "(" only saves 4 characters.
>>>
>>> How about this (suggestions for a shorter variable name - line is 97 characters)
>>>
>>> static char mba_mbps_invalid[] = "mba_MBps requires both MBM and (linear scale) MBA at L3 scope";
>>>
>>> rdt_parse_param(...)
>>> {
>>> 	...
>>> 	case Opt_mba_mbps:
>>> 		if (!supports_mba_mbps())
>>> 			return invalfc(fc, mba_mbps_invalid);
>>> 	...
>>> }
>>
>> On 6/20/24 3:12 PM, Luck, Tony wrote:
>>>> static char mba_mbps_invalid[] = "mba_MBps requires both MBM and (linear scale) MBA at L3 scope";
>>>
>>> checkpatch recommends "static const char ..." pushing this over 100 chars :-(
>>>
>>
>> How about something like below that reaches 96:
>>
>> 	case Opt_mba_mbps:
>> 		if (!supports_mba_mbps())
>> 			return invalfc(fc,
>> 				       "mba_MBps requires both MBM and linear MBA at L3 scope");
>>
> 
> Reinette,
> 
> Alternative option. Move the messaging into supports_mba_mbps() and
> split into shorter pieces for each reason. The other callers of
> supports_mba_mbps() that are just re-checking status would pass
> a NULL argument.

This fragmentation of the mount parameter checking, splitting its error
reporting to be partially into generic code, does not look ideal to me.

Looking at the information provided in the messages you created I can think
of two more options:

rdt_parse_param(...)
{
	...
	const char *msg;
	...

  	case Opt_mba_mbps:
		msg = "mba_MBps requires local MBM and linear scale MBA at L3 scope";
		if (!supports_mba_mbps())
  			return invalfc(fc, "%s", msg);
	...
}


rdt_parse_param(...)
{
	...
  	case Opt_mba_mbps:
		if (!supports_mba_mbps()) {
			errorfc(fc,
				"mba_MBps requires local MBM and linear scale MBA at L3 scope");
			return -EINVAL;
		}
	...
}

Reinette