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: <16348abf-44b3-4de5-88ee-adf6d0352c5e@arm.com>
Date: Fri, 20 Dec 2024 18:10:50 +0000
From: James Morse <james.morse@....com>
To: Reinette Chatre <reinette.chatre@...el.com>, x86@...nel.org,
 linux-kernel@...r.kernel.org
Cc: Fenghua Yu <fenghua.yu@...el.com>, 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>, Shaopeng Tan <tan.shaopeng@...fujitsu.com>
Subject: Re: [PATCH v5 03/40] x86/resctrl: Remove fflags from struct
 rdt_resource

Hi Reinette,

On 23/10/2024 22:03, Reinette Chatre wrote:
> On 10/4/24 11:03 AM, James Morse wrote:
>> The resctrl arch code specifies whether a resource controls a cache or
>> memory using the fflags field. This field is then used by resctrl to
>> determine which files should be exposed in the filesystem.
>>
>> Allowing the architecture to pick this value means the RFTYPE_
>> flags have to be in a shared header, and allows an architecture
>> to create a combination that resctrl does not support.
>>
>> Remove the fflags field, and pick the value based on the resource
>> id.

>> diff --git a/arch/x86/kernel/cpu/resctrl/rdtgroup.c b/arch/x86/kernel/cpu/resctrl/rdtgroup.c
>> index 6225d0b7e9ee..2abe17574407 100644
>> --- a/arch/x86/kernel/cpu/resctrl/rdtgroup.c
>> +++ b/arch/x86/kernel/cpu/resctrl/rdtgroup.c
>> @@ -2160,6 +2160,20 @@ static int rdtgroup_mkdir_info_resdir(void *priv, char *name,
>>  	return ret;
>>  }
>>  
>> +static u32 fflags_from_resource(struct rdt_resource *r)
> 
> What is motivation for the return type of u32? I am trying to understand why this is needed
> considering the value returned, variable it is assigned to, and the functions that use it
> (rdtgroup_mkdir_info_resdir() and rdtgroup_add_files()) all use unsigned long.

There are only 10 bits defined, it looks like I just auto-typed int, then corrected it to
u32, with the intention of the compiler generating a warning if it ever attempts to mask
in a values larger
than the return type.

I've changed it to unsigned-long.


>> +{
>> +	switch (r->rid) {
>> +	case RDT_RESOURCE_L3:
>> +	case RDT_RESOURCE_L2:
>> +		return RFTYPE_RES_CACHE;
>> +	case RDT_RESOURCE_MBA:
>> +	case RDT_RESOURCE_SMBA:
>> +		return RFTYPE_RES_MB;
>> +	}
>> +
>> +	return WARN_ON_ONCE(1);
>> +}
>> +
>>  static int rdtgroup_create_info_dir(struct kernfs_node *parent_kn)
>>  {
>>  	struct resctrl_schema *s;
>> @@ -2180,14 +2194,14 @@ static int rdtgroup_create_info_dir(struct kernfs_node *parent_kn)
>>  	/* loop over enabled controls, these are all alloc_capable */
>>  	list_for_each_entry(s, &resctrl_schema_all, list) {
>>  		r = s->res;
>> -		fflags = r->fflags | RFTYPE_CTRL_INFO;
>> +		fflags = fflags_from_resource(r) | RFTYPE_CTRL_INFO;
>>  		ret = rdtgroup_mkdir_info_resdir(s, s->name, fflags);
>>  		if (ret)
>>  			goto out_destroy;
>>  	}
>>  
>>  	for_each_mon_capable_rdt_resource(r) {
>> -		fflags = r->fflags | RFTYPE_MON_INFO;
>> +		fflags =  fflags_from_resource(r) | RFTYPE_MON_INFO;
> 
> Fixup did not make it here.

Fixed,


Thanks,

James

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ