From: Dave Martin <Dave.Martin@arm.com>
To: x86@kernel.org, linux-kernel@vger.kernel.org
Cc: James Morse <james.morse@arm.com>,
Fenghua Yu <fenghua.yu@intel.com>,
Reinette Chatre <reinette.chatre@intel.com>,
Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
H Peter Anvin <hpa@zytor.com>, Babu Moger <Babu.Moger@amd.com>,
shameerali.kolothum.thodi@huawei.com,
D Scott Phillips OS <scott@os.amperecomputing.com>,
carl@os.amperecomputing.com, lcherian@marvell.com,
bobo.shaobowang@huawei.com,
"Shaopeng Tan (Fujitsu)" <tan.shaopeng@fujitsu.com>,
baolin.wang@linux.alibaba.com,
Jamie Iles <quic_jiles@quicinc.com>,
Xin Hao <xhao@linux.alibaba.com>,
Peter Newman <peternewman@google.com>,
dfustini@baylibre.com, amitsinght@marvell.com,
David Hildenbrand <david@redhat.com>,
Rex Nie <rex.nie@jaguarmicro.com>
Subject: [PATCH] x86/resctrl: Don't try to free nonexistent RMIDs
Date: Fri, 14 Jun 2024 17:08:43 +0100 [thread overview]
Message-ID: <20240614160843.11006-1-Dave.Martin@arm.com> (raw)
Commit 6791e0ea3071 ("x86/resctrl: Access per-rmid structures by
index") adds logic to map individual monitoring groups into a
global index space used for tracking allocated RMIDs.
That patch keept the logic to ignore requests to free the default
RMID in free_rmid(), and this works fine on x86.
With arm64 MPAM, there is a latent bug here: on platforms with no
monitors exposed through resctrl, each control group still gets a
different monitoring group ID as seen by the hardware, since the
CLOSID always forms part of the monitoring group ID. This means
that when removing a control group, the code may try to free this
group's default monitoring group RMID for real. If there are no
monitors however, the RMID tracking table rmid_ptrs[] would be a
waste of memory and is never allocated, leading to a splat when a
free_rmid() tries to dereference the table.
One option would be to treat RMID 0 as special for every CLOSID,
but this would be ugly since we still want to do bookkeeping for
these monitoring group IDs when there are monitors present in the
hardware.
Instead, add a gating check of resctrl_arch_mon_capable() in
free_rmid(), and just do nothing if the hardware doesn't have
monitors.
This fix mirrors the gating checks already present in
mkdir_rdt_prepare_rmid_alloc() and elsewhere.
No functional change on x86.
Fixes: 6791e0ea3071 ("x86/resctrl: Access per-rmid structures by index")
Signed-off-by: Dave Martin <Dave.Martin@arm.com>
---
Based on v6.10-rc3.
Tested on x86 (But so far for the monitors-present case.
Testing on Atom would be appreciated.)
Tested on arm64 for the no-monitors case.
---
arch/x86/kernel/cpu/resctrl/monitor.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/x86/kernel/cpu/resctrl/monitor.c b/arch/x86/kernel/cpu/resctrl/monitor.c
index 2345e6836593..366f496ca3ce 100644
--- a/arch/x86/kernel/cpu/resctrl/monitor.c
+++ b/arch/x86/kernel/cpu/resctrl/monitor.c
@@ -519,7 +519,8 @@ void free_rmid(u32 closid, u32 rmid)
* allows architectures that ignore the closid parameter to avoid an
* unnecessary check.
*/
- if (idx == resctrl_arch_rmid_idx_encode(RESCTRL_RESERVED_CLOSID,
+ if (!resctrl_arch_mon_capable() ||
+ idx == resctrl_arch_rmid_idx_encode(RESCTRL_RESERVED_CLOSID,
RESCTRL_RESERVED_RMID))
return;
base-commit: 83a7eefedc9b56fe7bfeff13b6c7356688ffa670
--
2.34.1
next reply other threads:[~2024-06-14 16:08 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-06-14 16:08 Dave Martin [this message]
2024-06-14 22:47 ` [PATCH] x86/resctrl: Don't try to free nonexistent RMIDs Reinette Chatre
2024-06-17 11:55 ` Dave Martin
2024-06-17 15:53 ` Reinette Chatre
2024-06-18 9:30 ` Dave Martin
2024-06-18 15:43 ` Reinette Chatre
2024-06-18 16:16 ` Dave Martin
2024-06-18 17:08 ` Reinette Chatre
2024-06-19 12:54 ` Dave Martin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20240614160843.11006-1-Dave.Martin@arm.com \
--to=dave.martin@arm.com \
--cc=Babu.Moger@amd.com \
--cc=amitsinght@marvell.com \
--cc=baolin.wang@linux.alibaba.com \
--cc=bobo.shaobowang@huawei.com \
--cc=bp@alien8.de \
--cc=carl@os.amperecomputing.com \
--cc=david@redhat.com \
--cc=dfustini@baylibre.com \
--cc=fenghua.yu@intel.com \
--cc=hpa@zytor.com \
--cc=james.morse@arm.com \
--cc=lcherian@marvell.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=peternewman@google.com \
--cc=quic_jiles@quicinc.com \
--cc=reinette.chatre@intel.com \
--cc=rex.nie@jaguarmicro.com \
--cc=scott@os.amperecomputing.com \
--cc=shameerali.kolothum.thodi@huawei.com \
--cc=tan.shaopeng@fujitsu.com \
--cc=tglx@linutronix.de \
--cc=x86@kernel.org \
--cc=xhao@linux.alibaba.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox