[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <20250603125828.1590067-1-zengheng4@huawei.com>
Date: Tue, 3 Jun 2025 20:58:28 +0800
From: Zeng Heng <zengheng4@...wei.com>
To: <tony.luck@...el.com>, <reinette.chatre@...el.com>, <Dave.Martin@....com>,
<fenghuay@...dia.com>, <bp@...en8.de>, <james.morse@....com>
CC: <bobo.shaobowang@...wei.com>, <linux-kernel@...r.kernel.org>,
<x86@...nel.org>
Subject: [PATCH v2] fs/resctrl: Restore the rdt_last_cmd_clear() calls after acquiring rdtgroup_mutex
A lockdep fix removed two rdt_last_cmd_clear() calls that were used
to clear the last_cmd_status buffer but called without holding the
required rdtgroup_mutex. The impacted resctrl commands are:
writing to the cpus or cpus_list files and creating a new monitor
or control group. With stale data in the last_cmd_status buffer the
impacted resctrl commands report the stale error on success, or append
its own failure message to the stale error on failure.
Consequently, restore the rdt_last_cmd_clear() calls after acquiring
rdtgroup_mutex.
Fixes: c8eafe149530 ("x86/resctrl: Fix potential lockdep warning")
Signed-off-by: Zeng Heng <zengheng4@...wei.com>
---
Changes in v2:
1. Move rdt_last_cmd_clear() to be right after acquiring the mutex.
2. Rewrite the commit message in imperative tone, add explanation of the
error phenomenon.
Link to v1: https://lore.kernel.org/all/20250529113353.3275066-1-zengheng4@huawei.com/
fs/resctrl/rdtgroup.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/fs/resctrl/rdtgroup.c b/fs/resctrl/rdtgroup.c
index cc37f58b47dd..1beb124e25f6 100644
--- a/fs/resctrl/rdtgroup.c
+++ b/fs/resctrl/rdtgroup.c
@@ -536,6 +536,8 @@ static ssize_t rdtgroup_cpus_write(struct kernfs_open_file *of,
goto unlock;
}
+ rdt_last_cmd_clear();
+
if (rdtgrp->mode == RDT_MODE_PSEUDO_LOCKED ||
rdtgrp->mode == RDT_MODE_PSEUDO_LOCKSETUP) {
ret = -EINVAL;
@@ -3472,6 +3474,8 @@ static int mkdir_rdt_prepare(struct kernfs_node *parent_kn,
goto out_unlock;
}
+ rdt_last_cmd_clear();
+
/*
* Check that the parent directory for a monitor group is a "mon_groups"
* directory.
--
2.25.1
Powered by blists - more mailing lists