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

[Reinette Chatre <reinette.chatre@intel.com>]

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? 

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

Reinette