From: Jinjie Ruan <ruanjinjie@huawei.com>
To: Reinette Chatre <reinette.chatre@intel.com>,
<tony.luck@intel.com>, <Dave.Martin@arm.com>,
<james.morse@arm.com>, <babu.moger@amd.com>, <tglx@kernel.org>,
<x86@kernel.org>, <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] fs/resctrl: Report why a schemata write failed
Date: Thu, 5 Nov 2026 16:01:33 +0800 [thread overview]
Message-ID: <77449a5e-eafa-4648-9175-58519969d587@huawei.com> (raw)
In-Reply-To: <0bece210-cd99-4f4c-83cc-c58b59b7ebec@intel.com>
在 2026/11/5 3:18, Reinette Chatre 写道:
> Hi Jinjie,
>
> On 11/4/26 2:23 AM, Jinjie Ruan wrote:
>> rdtgroup_schemata_write() clears last_cmd_status when it takes the group
>> lock, and records a message for the input errors it detects. When
>> resctrl_arch_update_domains() fails, the function returns the error to
>> userspace without recording anything, so last_cmd_status is empty and
>> its show function reports "ok".
>>
>> resctrl_arch_update_domains() fails when the architecture code cannot
>> reach a domain, which on MPAM is a write to an MSC with no online CPU.
>
> How can this happen? Domain lifetime should be connected to the CPUs
> associated with it - if the domain has no online CPU then it should be
> invisible to resctrl.
Hi Reinette,
I agree, we free the domain if all related cpus offline.
The motivation description is incorrect.
>
> The fix is reasonable, the motivation is just unclear to me.
Will correct the motivation.
>
>> The error code is the only description of the failure available to an
>> administrator, and it never reaches last_cmd_status.
>>
>> Record the resource name and the error where rdtgroup_schemata_write()
>> discards the return value, so that last_cmd_status reports the failure
>> instead of the previous success.
>>
>> Only arm64 MPAM systems are affected today; x86's
>> resctrl_arch_update_domains() always returns 0.
>>
>> Fixes: c377dcfbee80 ("x86/intel_rdt: Add diagnostics when writing the schemata file")
>> Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
>> ---
>> fs/resctrl/ctrlmondata.c | 5 ++++-
>> 1 file changed, 4 insertions(+), 1 deletion(-)
>>
>> diff --git a/fs/resctrl/ctrlmondata.c b/fs/resctrl/ctrlmondata.c
>> index cafebdff70dc..cfb59cbc4135 100644
>> --- a/fs/resctrl/ctrlmondata.c
>> +++ b/fs/resctrl/ctrlmondata.c
>> @@ -367,8 +367,11 @@ ssize_t rdtgroup_schemata_write(struct kernfs_open_file *of,
>> continue;
>>
>> ret = resctrl_arch_update_domains(r, rdtgrp->closid);
>> - if (ret)
>> + if (ret) {
>> + rdt_last_cmd_printf("%s: failed to update the domains: %pe\n",
>> + r->name, ERR_PTR(ret));
>
> Please instead display the schema name (s->name) to user space as that is the name
> that the user use to interact with the schemata file.
Will update it.
> Is it necessary to print error code again? This is the same error returned to
> user space, no?
Not necessary indeed.
>
> I do not know what resctrl fs can claim here about hardware state - could such
> a write then partially succeed on MPAM side? If so, best fs can display may be
Yes, there are many failure paths for resctrl_arch_update_one() for one
domain.
> something like "failed to update all domains". If so, could user space follow this
> with a read of schemata file to see which domains failed? User may want to retry
> in such scenario ... but back to earlier question, this sounds like a permanent
Yes, that make sense for me.
> failure (until CPUs are back online) when attempting to make domain configuration
> changes that does not sound right here.
>
>> goto out_clear_staged;
>> + }
>> }
>>
>> if (rdtgrp->mode == RDT_MODE_PSEUDO_LOCKSETUP) {
>
> Reinette
--
Best regards,
Jinjie
next prev parent reply other threads:[~2026-11-05 8:01 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-04 10:23 Jinjie Ruan
2026-11-04 19:18 ` Reinette Chatre
2026-11-05 8:01 ` Jinjie Ruan [this message]
2026-11-05 8:32 ` Jinjie Ruan
2026-11-05 15:58 ` 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=77449a5e-eafa-4648-9175-58519969d587@huawei.com \
--to=ruanjinjie@huawei.com \
--cc=Dave.Martin@arm.com \
--cc=babu.moger@amd.com \
--cc=james.morse@arm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=reinette.chatre@intel.com \
--cc=tglx@kernel.org \
--cc=tony.luck@intel.com \
--cc=x86@kernel.org \
/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®