linux-kernel - Re: [PATCH v8 06/10] fs/resctrl: Add user interface to enable/disable io

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: <f0aa283f-2769-4701-a639-9917348d0cc0@amd.com>
Date: Tue, 2 Sep 2025 11:20:11 -0500
From: "Moger, Babu" <babu.moger@....com>
To: Reinette Chatre <reinette.chatre@...el.com>, corbet@....net,
 tony.luck@...el.com, Dave.Martin@....com, james.morse@....com,
 tglx@...utronix.de, mingo@...hat.com, bp@...en8.de,
 dave.hansen@...ux.intel.com
Cc: x86@...nel.org, hpa@...or.com, akpm@...ux-foundation.org,
 paulmck@...nel.org, rostedt@...dmis.org, Neeraj.Upadhyay@....com,
 david@...hat.com, arnd@...db.de, fvdl@...gle.com, seanjc@...gle.com,
 thomas.lendacky@....com, pawan.kumar.gupta@...ux.intel.com,
 yosry.ahmed@...ux.dev, sohil.mehta@...el.com, xin@...or.com,
 kai.huang@...el.com, xiaoyao.li@...el.com, peterz@...radead.org,
 me@...aill.net, mario.limonciello@....com, xin3.li@...el.com,
 ebiggers@...gle.com, ak@...ux.intel.com, chang.seok.bae@...el.com,
 andrew.cooper3@...rix.com, perry.yuan@....com, linux-doc@...r.kernel.org,
 linux-kernel@...r.kernel.org, manali.shukla@....com, gautham.shenoy@....com
Subject: Re: [PATCH v8 06/10] fs/resctrl: Add user interface to enable/disable
 io_alloc feature

Hi Reinette,

On 8/28/2025 9:47 PM, Reinette Chatre wrote:
> Hi Babu,
>
> On 8/27/25 1:39 PM, Moger, Babu wrote:
>> On 8/22/25 17:53, Moger, Babu wrote:
>>> On 8/7/2025 8:49 PM, Reinette Chatre wrote:
>>>> On 8/5/25 4:30 PM, Babu Moger wrote:
>>>>> +    enum resctrl_conf_type peer_type;
>>>>> +    struct resctrl_schema *peer_s;
>>>>> +    int ret;
>>>>> +
>>>>> +    rdt_staged_configs_clear();
>>>>> +
>>>>> +    ret = rdtgroup_init_cat(s, closid);
>>>>> +    if (ret < 0)
>>>>> +        goto out;
>>>>> +
>>>>> +    /* Initialize schema for both CDP_DATA and CDP_CODE when CDP is
>>>>> enabled */
>>>>> +    if (resctrl_arch_get_cdp_enabled(r->rid)) {
>>>>> +        peer_type = resctrl_peer_type(s->conf_type);
>>>>> +        peer_s = resctrl_get_schema(peer_type);
>>>>> +        if (peer_s) {
>>>>> +            ret = rdtgroup_init_cat(peer_s, closid);
>>>> This is unexpected. In v7 I suggested that when parsing the CBM of one
>>>> of the CDP
>>>> resources it is not necessary to do so again for the peer. The CBM can be
>>>> parsed *once* and the configuration just copied over. See:
>>>> https://lore.kernel.org/
>>>> lkml/82045638-2b26-4682-9374-1c3e400a580a@...el.com/
>>> Let met try to understand.
>>>
>>> So, rdtgroup_init_cat() sets up the staged _config for the specific CDP
>>> type for all the domains.
>>>
>>> We need to apply those staged_configs to its peer type on all the domains.
> To put it more directly, this implementation keeps the CBM of CDP_CODE and
> CDP_DATA in sync. Skipping the unnecessary and duplicate parsing and instead
> copying the CBM from one to the other makes that obvious.


Got it.

>
>>> Something like this?
>>>
>>> /* Initialize staged_config of the peer type when CDP is enabled */
>>>          if (resctrl_arch_get_cdp_enabled(r->rid)) {
>>>                  list_for_each_entry(d, &s->res->ctrl_domains, hdr.list) {
>>>                          cfg = &d->staged_config[s->conf_type];
>>>                          cfg_peer = &d->staged_config[peer_type];
>>>                          cfg_peer->new_ctrl = cfg->new_ctrl;
>>>                          cfg_peer->have_new_ctrl = cfg->have_new_ctrl;
>>>                  }
>>>          }
>>>
>> Replaced with following snippet.
>>
>> /* Initialize schema for both CDP_DATA and CDP_CODE when CDP is enabled */
> Could this be more specific? For example,
> "Keep CDP_CODE and CDP_DATA of io_alloc CLOSID's CBM in sync."


Sure.


>
>> +	if (resctrl_arch_get_cdp_enabled(r->rid)) {
>> +		peer_type = resctrl_peer_type(s->conf_type);
>> +		list_for_each_entry(d, &s->res->ctrl_domains, hdr.list)
>> +			memcpy(&d->staged_config[peer_type],
>> +			       &d->staged_config[s->conf_type],
>> +			       sizeof(*d->staged_config));
> This looks good to me. To make it obvious what types are dealt with this
> can instead use sizeof(d->staged_config[0]).


Sure. Thanks

Babu