From: "Luck, Tony" <tony.luck@intel.com>
To: Reinette Chatre <reinette.chatre@intel.com>
Cc: Fenghua Yu <fenghuay@nvidia.com>,
Maciej Wieczor-Retman <maciej.wieczor-retman@intel.com>,
Peter Newman <peternewman@google.com>,
James Morse <james.morse@arm.com>,
Babu Moger <babu.moger@amd.com>,
Drew Fustini <dfustini@baylibre.com>,
Dave Martin <Dave.Martin@arm.com>,
Anil Keshavamurthy <anil.s.keshavamurthy@intel.com>,
Chen Yu <yu.c.chen@intel.com>,
x86@kernel.org, linux-kernel@vger.kernel.org,
patches@lists.linux.dev
Subject: Re: [PATCH v5 06/29] x86,fs/resctrl: Improve domain type checking
Date: Wed, 4 Jun 2025 15:58:13 -0700 [thread overview]
Message-ID: <aEDPhbwyjzeum_Km@agluck-desk3> (raw)
In-Reply-To: <7de291ed-a29b-4768-9b27-7fd9f5602e37@intel.com>
On Tue, Jun 03, 2025 at 08:31:07PM -0700, Reinette Chatre wrote:
> Hi Tony,
>
> On 5/21/25 3:50 PM, Tony Luck wrote:
> > The rdt_domain_hdr structure is used in both control and monitor
> > domain structures to provide common methods for operations such as
> > adding a CPU to a domain, removing a CPU from a domain, accessing
> > the mask of all CPUs in a domain.
> >
> > The "type" field provides a simple check whether a domain is a
> > control or monitor domain so that programming errors operating
> > on domains will be quickly caught.
> >
> > To prepare for additional domain types that depend on the rdt_resource
> > to which they are connected add the resource id into the header
> > and check that in addition to the type.
> >
> > Signed-off-by: Tony Luck <tony.luck@intel.com>
> > ---
> > include/linux/resctrl.h | 9 +++++++++
> > arch/x86/kernel/cpu/resctrl/core.c | 10 ++++++----
> > fs/resctrl/ctrlmondata.c | 2 +-
> > 3 files changed, 16 insertions(+), 5 deletions(-)
> >
> > diff --git a/include/linux/resctrl.h b/include/linux/resctrl.h
> > index 40f2d0d48d02..d6b09952ef92 100644
> > --- a/include/linux/resctrl.h
> > +++ b/include/linux/resctrl.h
> > @@ -131,15 +131,24 @@ enum resctrl_domain_type {
> > * @list: all instances of this resource
> > * @id: unique id for this instance
> > * @type: type of this instance
> > + * @rid: index of resource for this domain
> > * @cpu_mask: which CPUs share this resource
> > */
> > struct rdt_domain_hdr {
> > struct list_head list;
> > int id;
> > enum resctrl_domain_type type;
> > + enum resctrl_res_level rid;
> > struct cpumask cpu_mask;
> > };
> >
> > +static inline bool domain_header_is_valid(struct rdt_domain_hdr *hdr,
> > + enum resctrl_domain_type type,
> > + enum resctrl_res_level rid)
> > +{
> > + return !WARN_ON_ONCE(hdr->type != type || hdr->rid != rid);
> > +}
> > +
> > /**
> > * struct rdt_ctrl_domain - group of CPUs sharing a resctrl control resource
> > * @hdr: common header for different domain types
> > diff --git a/arch/x86/kernel/cpu/resctrl/core.c b/arch/x86/kernel/cpu/resctrl/core.c
> > index 4403a820db12..4983f6f81218 100644
> > --- a/arch/x86/kernel/cpu/resctrl/core.c
> > +++ b/arch/x86/kernel/cpu/resctrl/core.c
> > @@ -456,7 +456,7 @@ static void domain_add_cpu_ctrl(int cpu, struct rdt_resource *r)
> >
> > hdr = resctrl_find_domain(&r->ctrl_domains, id, &add_pos);
> > if (hdr) {
> > - if (WARN_ON_ONCE(hdr->type != RESCTRL_CTRL_DOMAIN))
> > + if (!domain_header_is_valid(hdr, RESCTRL_CTRL_DOMAIN, r->rid))
> > return;
This type check was added as part of the split of the rdt_domain
structure into sepaarte ctrl and mon structures. I think the concern
was that some code might look at the wrong rdt_resource list and
try to operate on a ctrl domain structure that is actually a mon
structure (or vice versa). This felt like a real possibility.
Extending this to save and check the resource id seemed like a
natural extension at the time. But I'm starting to doubt the value
of doing so.
For this new check to ever fail we would have to somehow add
a domain for some resource type to a list on a different
rdt_resource structure. I'm struggling to see how such an
error could ever occur. Domains are only added to an rdt_resource
list by one of domain_add_cpu_ctrl() or domain_add_cpu_mon().
But these same functions are the ones to allocate the domain
structure and initialize the "d->hdr.id" field a dozen or so
lines earlier in the function.
Note that I'm not disputing your comments where my patches
are still passing a rdt_l3_mon_domain structure down through
several levels of function calls only to do:
if (r->rid == RDT_RESOURCE_PERF_PKG)
return intel_aet_read_event(d->hdr.id, rmid, eventid, val);
revealing that it wasn't an rdt_l3_mon_domain at all!
But these domain_header_is_valid() checks didn't help uncover
that.
Bottom line: I'd like to just keep the "type" check and not
extend to check the resource id.
> > d = container_of(hdr, struct rdt_ctrl_domain, hdr);
> >
>
> This is quite subtle and not obvious until a few patches later that the
> domain_header_is_valid() is done in preparation for using the
> rdt_domain_hdr::rid to verify that the correct containing structure is
> obtained in a subsequent container_of() call.
>
> Patch #10 mentions it explicitly: "Add sanity checks where
> container_of() is used to find the surrounding domain structure that
> hdr has the expected type."
>
> The change above, when combined with later changes, results in
> code like:
>
> if (!domain_header_is_valid(hdr, RESCTRL_MON_DOMAIN, r->rid))
> /* handle failure */
>
> d = container_of(hdr, struct rdt_l3_mon_domain, hdr);
> ...
>
> Considering this all I do not think using a variable r->rid is appropriate
> here. Specifically, if the code has it hardcoded that, for example,
> the containing structure is "struct rdt_l3_mon_domain" then should the
> test not similarly be hardcoded to ensure that rid is RDT_RESOURCE_L3?
>
> Reinette
-Tony
next prev parent reply other threads:[~2025-06-04 22:58 UTC|newest]
Thread overview: 90+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-05-21 22:50 [PATCH v5 00/29] x86/resctrl telemetry monitoring Tony Luck
2025-05-21 22:50 ` [PATCH v5 01/29] x86,fs/resctrl: Consolidate monitor event descriptions Tony Luck
2025-06-04 3:25 ` Reinette Chatre
2025-06-04 16:33 ` Luck, Tony
2025-06-04 18:24 ` Reinette Chatre
2025-05-21 22:50 ` [PATCH v5 02/29] x86,fs/resctrl: Replace architecture event enabled checks Tony Luck
2025-06-04 3:26 ` Reinette Chatre
2025-05-21 22:50 ` [PATCH v5 03/29] x86/resctrl: Remove 'rdt_mon_features' global variable Tony Luck
2025-06-04 3:27 ` Reinette Chatre
2025-05-21 22:50 ` [PATCH v5 04/29] x86,fs/resctrl: Prepare for more monitor events Tony Luck
2025-05-23 9:00 ` Peter Newman
2025-05-23 15:57 ` Luck, Tony
2025-06-04 3:29 ` Reinette Chatre
2025-06-07 0:45 ` Fenghua Yu
2025-06-08 21:59 ` Luck, Tony
2025-05-21 22:50 ` [PATCH v5 05/29] x86/rectrl: Fake OOBMSM interface Tony Luck
2025-05-23 23:38 ` Reinette Chatre
2025-05-27 20:25 ` [PATCH v5 05/29 UPDATED] x86/resctrl: " Tony Luck
2025-05-21 22:50 ` [PATCH v5 06/29] x86,fs/resctrl: Improve domain type checking Tony Luck
2025-06-04 3:31 ` Reinette Chatre
2025-06-04 22:58 ` Luck, Tony [this message]
2025-06-04 23:40 ` Reinette Chatre
2025-05-21 22:50 ` [PATCH v5 07/29] x86,fs/resctrl: Rename some L3 specific functions Tony Luck
2025-06-04 3:32 ` Reinette Chatre
2025-05-21 22:50 ` [PATCH v5 08/29] x86/resctrl: Move L3 initialization out of domain_add_cpu_mon() Tony Luck
2025-05-21 22:50 ` [PATCH v5 09/29] x86,fs/resctrl: Refactor domain_remove_cpu_mon() ready for new domain types Tony Luck
2025-06-04 3:32 ` Reinette Chatre
2025-05-21 22:50 ` [PATCH v5 10/29] x86/resctrl: Change generic domain functions to use struct rdt_domain_hdr Tony Luck
2025-05-22 0:01 ` Keshavamurthy, Anil S
2025-05-22 0:15 ` Luck, Tony
2025-06-04 3:37 ` Reinette Chatre
2025-06-07 0:52 ` Fenghua Yu
2025-06-08 22:02 ` Luck, Tony
2025-05-21 22:50 ` [PATCH v5 11/29] x86,fs/resctrl: Rename struct rdt_mon_domain and rdt_hw_mon_domain Tony Luck
2025-06-04 3:40 ` Reinette Chatre
2025-05-21 22:50 ` [PATCH v5 12/29] fs/resctrl: Make event details accessible to functions when reading events Tony Luck
2025-05-21 22:50 ` [PATCH v5 13/29] x86,fs/resctrl: Handle events that can be read from any CPU Tony Luck
2025-06-04 3:42 ` Reinette Chatre
2025-05-21 22:50 ` [PATCH v5 14/29] x86,fs/resctrl: Support binary fixed point event counters Tony Luck
2025-06-04 3:49 ` Reinette Chatre
2025-06-06 16:25 ` Luck, Tony
2025-06-06 16:56 ` Reinette Chatre
2025-06-10 15:16 ` Dave Martin
2025-06-10 15:54 ` Luck, Tony
2025-06-12 16:19 ` Dave Martin
2025-05-21 22:50 ` [PATCH v5 15/29] fs/resctrl: Add an architectural hook called for each mount Tony Luck
2025-06-04 3:49 ` Reinette Chatre
2025-05-21 22:50 ` [PATCH v5 16/29] x86/resctrl: Add and initialize rdt_resource for package scope core monitor Tony Luck
2025-05-21 22:50 ` [PATCH v5 17/29] x86/resctrl: Discover hardware telemetry events Tony Luck
2025-06-04 3:53 ` Reinette Chatre
2025-05-21 22:50 ` [PATCH v5 18/29] x86/resctrl: Count valid telemetry aggregators per package Tony Luck
2025-06-04 3:54 ` Reinette Chatre
2025-05-21 22:50 ` [PATCH v5 19/29] x86/resctrl: Complete telemetry event enumeration Tony Luck
2025-06-04 4:05 ` Reinette Chatre
2025-05-21 22:50 ` [PATCH v5 20/29] x86,fs/resctrl: Fill in details of Clearwater Forest events Tony Luck
2025-06-04 3:57 ` Reinette Chatre
2025-06-07 0:57 ` Fenghua Yu
2025-06-08 22:05 ` Luck, Tony
2025-05-21 22:50 ` [PATCH v5 21/29] x86/resctrl: x86/resctrl: Read core telemetry events Tony Luck
2025-06-04 4:02 ` Reinette Chatre
2025-05-21 22:50 ` [PATCH v5 22/29] x86,fs/resctrl: Handle domain creation/deletion for RDT_RESOURCE_PERF_PKG Tony Luck
2025-06-04 4:06 ` Reinette Chatre
2025-06-07 0:54 ` Fenghua Yu
2025-06-08 22:03 ` Luck, Tony
2025-05-21 22:50 ` [PATCH v5 23/29] x86/resctrl: Enable RDT_RESOURCE_PERF_PKG Tony Luck
2025-05-21 22:50 ` [PATCH v5 24/29] x86/resctrl: Add energy/perf choices to rdt boot option Tony Luck
2025-06-04 4:10 ` Reinette Chatre
2025-06-06 23:55 ` Fenghua Yu
2025-06-08 21:52 ` Luck, Tony
2025-05-21 22:50 ` [PATCH v5 25/29] x86/resctrl: Handle number of RMIDs supported by telemetry resources Tony Luck
2025-06-04 4:13 ` Reinette Chatre
2025-05-21 22:50 ` [PATCH v5 26/29] x86,fs/resctrl: Move RMID initialization to first mount Tony Luck
2025-05-21 22:50 ` [PATCH v5 27/29] fs/resctrl: Add file system mechanism for architecture info file Tony Luck
2025-06-04 4:15 ` Reinette Chatre
2025-06-06 0:09 ` Luck, Tony
2025-06-06 16:26 ` Reinette Chatre
2025-06-06 17:30 ` Luck, Tony
2025-06-06 21:14 ` Reinette Chatre
2025-06-09 18:49 ` Luck, Tony
2025-06-09 22:39 ` Reinette Chatre
2025-06-09 23:34 ` Luck, Tony
2025-06-10 0:30 ` Reinette Chatre
2025-06-10 18:48 ` Luck, Tony
2025-05-21 22:50 ` [PATCH v5 28/29] x86/resctrl: Add info/PERF_PKG_MON/status file Tony Luck
2025-05-21 22:50 ` [PATCH v5 29/29] x86/resctrl: Update Documentation for package events Tony Luck
2025-05-28 17:21 ` [PATCH v5 00/29] x86/resctrl telemetry monitoring Reinette Chatre
2025-05-28 21:38 ` Luck, Tony
2025-05-28 22:21 ` Reinette Chatre
2025-06-13 16:57 ` James Morse
2025-06-13 18:50 ` Luck, Tony
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=aEDPhbwyjzeum_Km@agluck-desk3 \
--to=tony.luck@intel.com \
--cc=Dave.Martin@arm.com \
--cc=anil.s.keshavamurthy@intel.com \
--cc=babu.moger@amd.com \
--cc=dfustini@baylibre.com \
--cc=fenghuay@nvidia.com \
--cc=james.morse@arm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=maciej.wieczor-retman@intel.com \
--cc=patches@lists.linux.dev \
--cc=peternewman@google.com \
--cc=reinette.chatre@intel.com \
--cc=x86@kernel.org \
--cc=yu.c.chen@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).