From: Reinette Chatre <reinette.chatre@intel.com>
To: "Shaopeng Tan (Fujitsu)" <tan.shaopeng@fujitsu.com>,
"ben.horgan@arm.com" <ben.horgan@arm.com>,
"james.morse@arm.com" <james.morse@arm.com>,
"Dave.Martin@arm.com" <Dave.Martin@arm.com>,
"fenghuay@nvidia.com" <fenghuay@nvidia.com>
Cc: "tony.luck@intel.com" <tony.luck@intel.com>,
"yu.c.chen@intel.com" <yu.c.chen@intel.com>,
"babu.moger@amd.com" <babu.moger@amd.com>,
"fustini@kernel.org" <fustini@kernel.org>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"patches@lists.linux.dev" <patches@lists.linux.dev>
Subject: Re: [RFC PATCH v2 04/10] arm_mpam: resctrl: Split control and monitoring domain setup into helpers
Date: Mon, 2 Nov 2026 09:20:42 -0800 [thread overview]
Message-ID: <3a06c4c8-51cb-4636-b95e-d6decf33d9a5@intel.com> (raw)
In-Reply-To: <TY4PR01MB16930DAEC61D558A935F8C27E8B6A2@TY4PR01MB16930.jpnprd01.prod.outlook.com>
Hi Shaopeng,
Thank you very much for taking a look.
On 11/1/26 9:41 PM, Shaopeng Tan (Fujitsu) wrote:
...
>> diff --git a/drivers/resctrl/mpam_resctrl.c b/drivers/resctrl/mpam_resctrl.c
>> index dc442851fd7e..246560247a28 100644
>> --- a/drivers/resctrl/mpam_resctrl.c
>> +++ b/drivers/resctrl/mpam_resctrl.c
>> @@ -1615,13 +1615,77 @@ static struct mpam_component *find_component(struct mpam_class *class, int cpu)
>> return NULL;
>> }
>>
>> +static int mpam_resctrl_setup_ctrl_domain(unsigned int cpu,
>> + struct rdt_resource *r,
>> + struct mpam_component *comp,
>> + struct mpam_resctrl_dom *dom)
>> +{
>> + struct rdt_ctrl_domain *ctrl_d = &dom->resctrl_ctrl_dom;
>> + int err;
>> +
>> + dom->ctrl_comp = comp;
>> +
>> + mpam_resctrl_domain_hdr_init(cpu, comp, r->rid, &ctrl_d->hdr);
>> + ctrl_d->hdr.type = RESCTRL_CTRL_DOMAIN;
>> + err = resctrl_online_ctrl_domain(r, ctrl_d);
>> + if (err)
>> + return err;
>> +
>> + mpam_resctrl_domain_insert(&r->ctrl_domains, &ctrl_d->hdr);
>> +
>> + return 0;
>> +}
>> +
>> +static int mpam_resctrl_setup_mon_domain(unsigned int cpu,
>> + struct rdt_resource *r,
>> + struct mpam_resctrl_dom *dom)
>> +{
>> + struct rdt_l3_mon_domain *mon_d = &dom->resctrl_mon_dom;
>> + struct mpam_component *any_mon_comp = NULL;
>> + enum resctrl_event_id eventid;
>> + struct mpam_resctrl_mon *mon;
>> + int err;
>> +
>> + /*
>> + * Even if the monitor domain is backed by a different
>> + * component, the L3 component IDs need to be used... only
>> + * there may be no ctrl_comp for the L3.
>> + * Search each event's class list for a component with
>> + * overlapping CPUs and set up the dom->mon_comp array.
>> + */
>> +
>> + for_each_mpam_resctrl_mon(mon, eventid) {
>> + struct mpam_component *mon_comp;
>> +
>> + if (!mon->class)
>> + continue; // dummy resource
>> +
>> + mon_comp = find_component(mon->class, cpu);
>> + dom->mon_comp[eventid] = mon_comp;
>> + if (mon_comp)
>> + any_mon_comp = mon_comp;
>> + }
>> + if (!any_mon_comp) {
>> + WARN_ON_ONCE(0);
>> + return -EFAULT;
>> + }
>> +
>> + mpam_resctrl_domain_hdr_init(cpu, any_mon_comp, r->rid, &mon_d->hdr);
>> + mon_d->hdr.type = RESCTRL_MON_DOMAIN;
>> + err = resctrl_online_mon_domain(r, &mon_d->hdr);
>> + if (err)
>> + return err;
>> +
>> + mpam_resctrl_domain_insert(&r->mon_domains, &mon_d->hdr);
>> +
>> + return 0;
>> +}
>> +
>
> Currently, it returns success even when the domain fails to be inserted. Is there a specific reason for this design?
> I believe it would be safer if mpam_resctrl_domain_insert() returned an int to indicate success or failure.
>
> For example:
> static int mpam_resctrl_domain_insert(struct list_head *list,
> struct rdt_domain_hdr *new)
Could mpam_resctrl_domain_insert() ever fail? A domain is only created
after the lookup found none for this CPU. For a control domain the lookup is by
the component's CPU affinity while the insert checks the domain id, but the id
is the component's id and component affinities within a class do not overlap, so
absence of one implies absence of the other. For a monitoring domain both are
the L3 cache id.
For mpam_resctrl_domain_insert() to return a failure an insert would have found
an existing domain which means a domain appeared _after_ it was found to be absent.
That would be a driver bug rather than a runtime error. The WARN_ON_ONCE() reports
it. Handling it would add unwind code for a state that cannot occur.
This is how I understand the flow and believe this is why the existing code
does not report it.
Reinette
next prev parent reply other threads:[~2026-11-02 17:20 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-19 22:07 [RFC PATCH v2 00/10] arm_mpam: resctrl: Separate MPAM domains Reinette Chatre
2026-10-19 22:07 ` [RFC PATCH v2 01/10] arm_mpam: resctrl: Use find_component() when allocating a domain Reinette Chatre
2026-10-23 8:07 ` Jinjie Ruan
2026-10-23 8:07 ` Jinjie Ruan
2026-10-23 14:52 ` Reinette Chatre
2026-10-19 22:07 ` [RFC PATCH v2 02/10] arm_mpam: resctrl: Rename ctrl_comp in mpam_resctrl_alloc_domain() Reinette Chatre
2026-10-23 8:08 ` Jinjie Ruan
2026-10-23 14:53 ` Reinette Chatre
2026-10-19 22:07 ` [RFC PATCH v2 03/10] arm_mpam: resctrl: Do not fail CPU online when domain setup fails Reinette Chatre
2026-10-26 9:51 ` Jinjie Ruan
2026-10-19 22:07 ` [RFC PATCH v2 04/10] arm_mpam: resctrl: Split control and monitoring domain setup into helpers Reinette Chatre
2026-10-26 11:49 ` Jinjie Ruan
2026-11-02 5:41 ` Shaopeng Tan (Fujitsu)
2026-11-02 17:20 ` Reinette Chatre [this message]
2026-10-19 22:07 ` [RFC PATCH v2 05/10] arm_mpam: resctrl: Give the monitoring domain its own structure Reinette Chatre
2026-10-26 12:14 ` Jinjie Ruan
2026-10-26 16:55 ` Reinette Chatre
2026-10-27 1:12 ` Jinjie Ruan
2026-10-19 22:07 ` [RFC PATCH v2 06/10] arm_mpam: resctrl: Rename struct mpam_resctrl_dom to mpam_resctrl_ctrl_dom Reinette Chatre
2026-10-26 12:40 ` Jinjie Ruan
2026-10-19 22:07 ` [RFC PATCH v2 07/10] arm_mpam: resctrl: Warn when no monitoring component is found for a CPU Reinette Chatre
2026-10-26 13:14 ` Jinjie Ruan
2026-10-19 22:07 ` [RFC PATCH v2 08/10] arm_mpam: resctrl: Require a component for each monitoring event Reinette Chatre
2026-10-19 22:07 ` [RFC PATCH v2 09/10] arm_mpam: resctrl: Require monitoring components to cover the same CPUs Reinette Chatre
2026-10-19 22:07 ` [RFC PATCH v2 10/10] arm_mpam: resctrl: Update the comment on monitoring domain setup Reinette Chatre
2026-10-22 10:45 ` [RFC PATCH v2 00/10] arm_mpam: resctrl: Separate MPAM domains Ben Horgan
2026-10-22 15:43 ` Reinette Chatre
2026-10-27 3:42 ` Jinjie Ruan
2026-10-27 14:23 ` Reinette Chatre
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=3a06c4c8-51cb-4636-b95e-d6decf33d9a5@intel.com \
--to=reinette.chatre@intel.com \
--cc=Dave.Martin@arm.com \
--cc=babu.moger@amd.com \
--cc=ben.horgan@arm.com \
--cc=fenghuay@nvidia.com \
--cc=fustini@kernel.org \
--cc=james.morse@arm.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=patches@lists.linux.dev \
--cc=tan.shaopeng@fujitsu.com \
--cc=tony.luck@intel.com \
--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
all inboxes | Powered by JetHome®