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

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

[Jinjie Ruan]

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.
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));
 			goto out_clear_staged;
+		}
 	}
 
 	if (rdtgrp->mode == RDT_MODE_PSEUDO_LOCKSETUP) {
-- 
2.34.1

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

[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.

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

Reinette

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

[Jinjie Ruan]

在 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

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

[Jinjie Ruan]

在 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

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

[Reinette Chatre]

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