Re: [PATCH] fs/resctrl: Report why a schemata write failed

[Jinjie Ruan <ruanjinjie@huawei.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.
> 
> The fix is reasonable, the motivation is just unclear to me.
> 
>> 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. 
> Is it necessary to print error code again? This is the same error returned to
> user space, no?
> 
> 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
> 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
> failure (until CPUs are back online) when attempting to make domain configuration
> changes that does not sound right here.

There are some cases not permanent:

- PCC/MPAM-Fb MSC returns -EIO in case of protocol errors or timeouts
（mpam_fb_send_request() or smp_call_on_cpu()）;

- -EINVAL when the calculated PARTID is out of bounds
(resctrl_arch_update_one()).

Both will roll back and retry after the cause is resolved will succeed.

I verified these error cases using fault inject for mpam_touch_msc().


> 
>>  			goto out_clear_staged;
>> +		}
>>  	}
>>  
>>  	if (rdtgrp->mode == RDT_MODE_PSEUDO_LOCKSETUP) {
> 
> Reinette

-- 
Best regards,
Jinjie