arch/x86/kernel/cpu/resctrl/monitor.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
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 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>
Tested-by: Reinette Chatre <reinette.chatre@intel.com>
Reviewed-by: Reinette Chatre <reinette.chatre@intel.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.
Changes since v1:
* Typo fixes and rewording in commit message; slurp maintainer tags.
(no code changes)
---
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
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;
On Wed, Jun 19, 2024 at 09:55:24AM -0000, tip-bot2 for Dave Martin wrote:
> 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.
[...]
> [ bp: Massage commit message. ]
Thanks Boris for picking this up.
Is there a preferred line length for commit messages in tip? I don't
see anything in maintainer-tip.rst about this.
This commit message now looks a mess on a regular terminal, since git
log indents the start of each line by four columns.
Maintainer's choice, I guess, but just in case this effect is not
intentional I thought I ought to draw attention to it.
Cheers
---Dave
On Wed, Jun 19, 2024 at 01:51:34PM +0100, Dave Martin wrote:
> This commit message now looks a mess on a regular terminal, since git
> log indents the start of each line by four columns.
Well, we got rid of the 80 cols rule a long time ago so if you're looking at
kernel code in that same terminal, you're looking at a similar mess?
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
Hi Boris, On Wed, Jun 19, 2024 at 03:45:22PM +0200, Borislav Petkov wrote: > On Wed, Jun 19, 2024 at 01:51:34PM +0100, Dave Martin wrote: > > This commit message now looks a mess on a regular terminal, since git > > log indents the start of each line by four columns. > > Well, we got rid of the 80 cols rule a long time ago so if you're looking at > kernel code in that same terminal, you're looking at a similar mess? <bikeshed> It's still a guideline, no? (Though I admit that common sense has to apply and there are quite often good reasons to bust the limit in code.) But commit messages are not code, and don't suffer from creeping indentation that eats up half of each line, so the rationale is not really the same. In block text, lines near maximum length are common, but when looking at code OTOH, long lines are usually rare, so the file is not rendered unreadable without linewrap turned off or a bigger terminal. For git logs, git config core.pager 'less -S' makes things a little better I suppose, since that at least keeps the left-hand columns blank on the commit message lines, making the log easier to skim through by eye. There doesn't seem to be a way to bind a key to flip line wrapping on and off in less at runtime, though I've not dug into it. </bikeshed> Anyway, I was just mildly surprised, it's not a huge deal. > -- > Regards/Gruss, > Boris. > > https://people.kernel.org/tglx/notes-about-netiquette (Quoted: "Text-based e-mail should not exceed 80 columns per line of text. Consult the documentation of your e-mail client to enable proper line breaks around column 78.". No statement about commit messages, and "should not exceed" is not the same as "should be wrapped to". This document doesn't seem to consider how git formats text derived from emails.) Cheers ---Dave
On Wed, Jun 19, 2024 at 05:03:03PM +0100, Dave Martin wrote:
> It's still a guideline, no? (Though I admit that common sense has to
> apply and there are quite often good reasons to bust the limit in
> code.) But commit messages are not code, and don't suffer from
> creeping indentation that eats up half of each line, so the rationale
> is not really the same.
Just do a "git log" on mainline and marvel at all the possible "formatting".
The ship on being able to read commit messages with formatting that fits what
you're expecting has long sailed.
> Anyway, I was just mildly surprised, it's not a huge deal.
Yeah, we don't have a strict rule. And I don't think you can make everyone
agree and then adhere to some rule for commit messages width. But hey... :-)
> (Quoted: "Text-based e-mail should not exceed 80 columns per line of
> text. Consult the documentation of your e-mail client to enable proper
> line breaks around column 78.". No statement about commit messages,
> and "should not exceed" is not the same as "should be wrapped to".
> This document doesn't seem to consider how git formats text derived
> from emails.)
See above.
I'm willing to consider a rule for commit messages if the majority agrees on
some rule.
Thx.
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
Hi,
On Wed, Jun 19, 2024 at 06:21:24PM +0200, Borislav Petkov wrote:
> On Wed, Jun 19, 2024 at 05:03:03PM +0100, Dave Martin wrote:
> > It's still a guideline, no? (Though I admit that common sense has to
> > apply and there are quite often good reasons to bust the limit in
> > code.) But commit messages are not code, and don't suffer from
> > creeping indentation that eats up half of each line, so the rationale
> > is not really the same.
>
> Just do a "git log" on mainline and marvel at all the possible "formatting".
>
> The ship on being able to read commit messages with formatting that fits what
> you're expecting has long sailed.
Well, not exactly "expecting", but unfamiliar. I've mostly been living
in in arch/arm{,64}/ where it's common to have lines a little shorter.
> > Anyway, I was just mildly surprised, it's not a huge deal.
>
> Yeah, we don't have a strict rule. And I don't think you can make everyone
> agree and then adhere to some rule for commit messages width. But hey... :-)
>
> > (Quoted: "Text-based e-mail should not exceed 80 columns per line of
> > text. Consult the documentation of your e-mail client to enable proper
> > line breaks around column 78.". No statement about commit messages,
> > and "should not exceed" is not the same as "should be wrapped to".
> > This document doesn't seem to consider how git formats text derived
> > from emails.)
>
> See above.
>
> I'm willing to consider a rule for commit messages if the majority agrees on
> some rule.
>
> Thx.
I guess my issue is that the "Massage commit message" seems to document
a criticism that the author was careless, didn't follow a rule, or that
the commit message was defective in some way, with the author having no
right of reply (at least, not recorded in the git history).
I may just be being too touchy.
Anyway, thanks for picking up the patch -- I'm not trying to make extra
work for anyone.
Cheers
---Dave
On Thu, Jun 20, 2024 at 12:36:43PM +0100, Dave Martin wrote:
> I guess my issue is that the "Massage commit message" seems to document
> a criticism that the author was careless, didn't follow a rule, or that
> the commit message was defective in some way, with the author having no
> right of reply (at least, not recorded in the git history).
Not necessarily - that's what you said. I massage commit messages because they
need some touch ups sometimes.
In your case I rewrote the sentence with "we" because "we" is ambiguous in
commit messages. I also broke up this biggish paragraph into smaller chunks to
make it more readable.
> I may just be being too touchy.
>
> Anyway, thanks for picking up the patch -- I'm not trying to make extra
> work for anyone.
I look at it this way: I don't always agree with other maintainers' choices
either but this is the reality: every maintainer has their own
requirements/views/etc on how the code and commit messages are going to look,
yadda yadda. And to some extent that's their prerogative.
But we have a *lot* *bigger* fish to fry so I'm going to stop debating here as
everything was already said.
Thx.
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
On Thu, Jun 20, 2024 at 01:53:05PM +0200, Borislav Petkov wrote: > On Thu, Jun 20, 2024 at 12:36:43PM +0100, Dave Martin wrote: > > I guess my issue is that the "Massage commit message" seems to document > > a criticism that the author was careless, didn't follow a rule, or that > > the commit message was defective in some way, with the author having no > > right of reply (at least, not recorded in the git history). > > Not necessarily - that's what you said. I massage commit messages because they > need some touch ups sometimes. > > In your case I rewrote the sentence with "we" because "we" is ambiguous in That _was_ unintentional, so apologies for that. > commit messages. I also broke up this biggish paragraph into smaller chunks to > make it more readable. > > > I may just be being too touchy. > > > > Anyway, thanks for picking up the patch -- I'm not trying to make extra > > work for anyone. > > I look at it this way: I don't always agree with other maintainers' choices > either but this is the reality: every maintainer has their own > requirements/views/etc on how the code and commit messages are going to look, > yadda yadda. And to some extent that's their prerogative. > > But we have a *lot* *bigger* fish to fry so I'm going to stop debating here as > everything was already said. > > Thx. > > -- > Regards/Gruss, > Boris. > > https://people.kernel.org/tglx/notes-about-netiquette > Ack; apologies for the noise. Cheers ---Dave
© 2016 - 2025 Red Hat, Inc.