linux-kernel - Re: [PATCH v4 03/24] x86/resctrl: Add a separate schema list for 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]

Date:   Thu, 17 Jun 2021 18:02:59 +0100
From:   James Morse <james.morse@....com>
To:     Babu Moger <babu.moger@....com>, x86@...nel.org,
        linux-kernel@...r.kernel.org
Cc:     Fenghua Yu <fenghua.yu@...el.com>,
        Reinette Chatre <reinette.chatre@...el.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
        H Peter Anvin <hpa@...or.com>,
        shameerali.kolothum.thodi@...wei.com,
        Jamie Iles <jamie@...iainc.com>,
        D Scott Phillips OS <scott@...amperecomputing.com>,
        lcherian@...vell.com
Subject: Re: [PATCH v4 03/24] x86/resctrl: Add a separate schema list for
 resctrl

Hi Babu,

On 15/06/2021 18:51, Babu Moger wrote:
> On 6/14/21 3:09 PM, James Morse wrote:
>> Resctrl exposes schemata to user-space, which allow the control values
>> to be specified for a group of tasks.
>>
>> User-visible properties of the interface, (such as the schemata names
>> and how the values are parsed) are rooted in a struct provided by the
>> architecture code. (struct rdt_hw_resource). Once a second architecture
>> uses resctrl, this would allow user-visible properties to diverge
>> between architectures.
>>
>> These properties should come from the resctrl code that will be common
>> to all architectures. Resctrl has no per-schema structure, only struct
>> rdt_{hw_,}resource. Create a struct resctrl_schema to hold the
>> rdt_resource. Before a second architecture can be supported, this
>> structure will also need to hold the schema name visible to user-space
>> and the type of configuration values for resctrl.

>> diff --git a/include/linux/resctrl.h b/include/linux/resctrl.h
>> index be6f5df78e31..425e7913dc8d 100644
>> --- a/include/linux/resctrl.h
>> +++ b/include/linux/resctrl.h
>> @@ -154,4 +154,15 @@ struct rdt_resource {
>>  
>>  };
>>  
>> +/**
>> + * struct resctrl_schema - configuration abilities of a resource presented to
>> + *			   user-space
>> + * @list:	Member of resctrl_schema_all.
>> + * @res:	The resource structure exported by the architecture to describe
>> + *		the hardware that is configured by this schema.
>> + */
>> +struct resctrl_schema {
>> +	struct list_head		list;
>> +	struct rdt_resource		*res;

> It will be better to be consistent with the naming.
>         struct rdt_resource		*resctrl;

Consistent with what? The rest of the code base conventionally calls a resource 'r'.

The structures with '_hw_' are private to the architecture, the 'resctrl' structure there
is the part of the struct that the architecture makes visible to the filesystem of that name.

That pattern doesn't apply here, 'struct resctrl_schema' is an invention of the
filesystem, the architecture code doesn't need to know anything about it. (this is why it
goes in include/linux from the beginning).


I think the choices are 'r', (too terse), 'resource' (too much typing, obvious from the
type), or 'res'...


Thanks!

James