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

[Ben Horgan <ben.horgan@arm.com>]

Hi Jinjie, Reinette,

On 05/11/2026 15:58, Reinette Chatre wrote:
> Hi Jinjie,
> 
> On 11/5/26 12:32 AM, Jinjie Ruan wrote:
>> 在 2026/11/5 3:18, Reinette Chatre 写道:
>>> On 11/4/26 2:23 AM, Jinjie Ruan wrote:
> ...
> 
>>>> 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.
> 
> Could you please provide more detail about the above "roll back and retry"? 
> 
> I am trying to view this from user space side. The "PARTID is out of bounds"
> sounds like a bug in the "should never happen" category. I am not familiar
> with everything that can fall into the "protocol errors or timeouts"  bucket.
> Would it be worthwhile for user to try again when these are encountered?
> Could "-EBUSY" be more appropriate to help user know when it is worthwhile
> to retry? If it is not possible to retry, does that mean a permanent failure
> for which the domain should rather be removed to prevent user from encountering
> the same issue over and over?

Any MPAM-Fb error is considered unrecoverable and triggers a disable of
MPAM. (The same response as to an MPAM error interrupt.) This in turn
disables resctrl on that system. Errors are still reported to resctrl so
that the user doesn't see success for an action even if any subsequent
action will fail. This policy may be revisited, in the future, if we
encounter systems where there are recoverable MPAM-Fb errors that are
actually seen to happen. The first line of defense would be a retry
within the MPAM driver and then if that is insufficent reporting a
timeout to the user.

As it stands I don't think the user will have time after a MPAM-Fb
failure to read the last_cmd_status before the resctrl filesystem is
torn down.

Thanks,

Ben

> 
>>
>> I verified these error cases using fault inject for mpam_touch_msc().
>>
> Thank you very much for all this testing.
> 
> Reinette
> 
>