From: "tip-bot2 for Dave Martin" <tip-bot2@linutronix.de>
To: linux-tip-commits@vger.kernel.org
Cc: Dave Martin <Dave.Martin@arm.com>,
"Borislav Petkov (AMD)" <bp@alien8.de>,
Reinette Chatre <reinette.chatre@intel.com>,
x86@kernel.org, linux-kernel@vger.kernel.org
Subject: [tip: x86/urgent] x86/resctrl: Don't try to free nonexistent RMIDs
Date: Wed, 19 Jun 2024 09:55:24 -0000 [thread overview]
Message-ID: <171879092443.10875.1695191697085701044.tip-bot2@tip-bot2> (raw)
In-Reply-To: <20240618140152.83154-1-Dave.Martin@arm.com>
The following commit has been merged into the x86/urgent branch of tip:
Commit-ID: 739c9765793e5794578a64aab293c58607f1826a
Gitweb: https://git.kernel.org/tip/739c9765793e5794578a64aab293c58607f1826a
Author: Dave Martin <Dave.Martin@arm.com>
AuthorDate: Tue, 18 Jun 2024 15:01:52 +01:00
Committer: Borislav Petkov (AMD) <bp@alien8.de>
CommitterDate: Wed, 19 Jun 2024 11:39:09 +02:00
x86/resctrl: Don't try to free nonexistent RMIDs
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.
Attempts to free the default RMID are ignored in free_rmid(), and this works
fine on x86.
With arm64 MPAM, there is a latent bug here however: 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 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 bookkeeping still needs to be done 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.
[ bp: Massage commit message. ]
Fixes: 6791e0ea3071 ("x86/resctrl: Access per-rmid structures by index")
Signed-off-by: Dave Martin <Dave.Martin@arm.com>
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
Reviewed-by: Reinette Chatre <reinette.chatre@intel.com>
Tested-by: Reinette Chatre <reinette.chatre@intel.com>
Link: https://lore.kernel.org/r/20240618140152.83154-1-Dave.Martin@arm.com
---
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 2345e68..366f496 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;
next prev parent reply other threads:[~2024-06-19 10:01 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-06-18 14:01 [PATCH v2] " Dave Martin
2024-06-19 9:55 ` tip-bot2 for Dave Martin [this message]
2024-06-19 12:51 ` [tip: x86/urgent] " Dave Martin
2024-06-19 13:45 ` Borislav Petkov
2024-06-19 16:03 ` Dave Martin
2024-06-19 16:21 ` Borislav Petkov
2024-06-20 11:36 ` Dave Martin
2024-06-20 11:53 ` Borislav Petkov
2024-06-20 12:38 ` 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=171879092443.10875.1695191697085701044.tip-bot2@tip-bot2 \
--to=tip-bot2@linutronix.de \
--cc=Dave.Martin@arm.com \
--cc=bp@alien8.de \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-tip-commits@vger.kernel.org \
--cc=reinette.chatre@intel.com \
--cc=x86@kernel.org \
/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
all inboxes | Powered by JetHome®