[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