linux-kernel - Re: [PATCH v5 03/40] x86/resctrl: Remove fflags from struct rdt

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: <8d4896ea-9bb5-4565-b678-51a63c560747@intel.com>
Date: Wed, 23 Oct 2024 14:03:35 -0700
From: Reinette Chatre <reinette.chatre@...el.com>
To: James Morse <james.morse@....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 James,

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.
> 
> Signed-off-by: James Morse <james.morse@....com>
> Tested-by: Shaopeng Tan <tan.shaopeng@...fujitsu.com>
> Reviewed-by: Shaopeng Tan <tan.shaopeng@...fujitsu.com>
> ---
> Changes since v4:
>  * Removed an extra space

Looks like this fixup was squashed into the next patch instead.

>  * Fixed a typo
> ---


> 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.

> +{
> +	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.

Reinette