linux-kernel - Re: [PATCH v9 2/8] x86/resctrl: Prepare to split 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: <b4053448-8ea7-47e5-be6a-d206f7d7a268@intel.com>
Date:   Mon, 30 Oct 2023 14:19:11 -0700
From:   Reinette Chatre <reinette.chatre@...el.com>
To:     Tony Luck <tony.luck@...el.com>, Fenghua Yu <fenghua.yu@...el.com>,
        "Peter Newman" <peternewman@...gle.com>,
        Jonathan Corbet <corbet@....net>,
        Shuah Khan <skhan@...uxfoundation.org>, <x86@...nel.org>
CC:     Shaopeng Tan <tan.shaopeng@...itsu.com>,
        James Morse <james.morse@....com>,
        Jamie Iles <quic_jiles@...cinc.com>,
        Babu Moger <babu.moger@....com>,
        Randy Dunlap <rdunlap@...radead.org>,
        <linux-kernel@...r.kernel.org>, <linux-doc@...r.kernel.org>,
        <patches@...ts.linux.dev>
Subject: Re: [PATCH v9 2/8] x86/resctrl: Prepare to split rdt_domain structure

Hi Tony,

On 10/20/2023 2:30 PM, Tony Luck wrote:
> The rdt_domain structure is used for both control and monitor features.
> It is about to be split into separate structures for these two usages
> because the scope for control and monitoring features for a resource
> will be different for future resources.
> 
> To allow for common code that scans a list of domains looking for a
> specific domain id, move the "list" and "id" fields into their own
> structure within the rdt_domain structure.

The motivation for this split is not clear to me. Here the motivation
is to support the code that needs to traverse both lists. Later (patch #4)
the motivation is that what remains should be "just the fields required for
control and monitoring respectively". The comment "common header for different
domain types" also makes me think this new structure should contain all
common members?
The reason why the motivation needs to be clear in this regard is because
there is a common field, cpu_mask, that did not make it into the header.
Should it?

> Add a "type" field to the header to be used later so that callers looking
> up a domain can be assured that they found one of the expected type.

Please move this addition to when it is used.

Reinette