Patch "x86/mce: Remove noinstr annotation from mce_setup()" has been added to the 5.15-stable tree
A message that is not in the archive (sent off-list or not yet received): [email protected]
A message that is not in the archive (sent off-list or not yet received): YeAnLb7OkkmTWtf/@zn.tnic
Greg KH
maintainerQuoted 39 lines · Borislav Petkov
Quoted 31 lines · On Thu, Jan 13, 2022 at 01:59:00PM +0100, [email protected] wrote:
This is a note to let you know that I've just added the patch titled
x86/mce: Remove noinstr annotation from
mce_setup()to the 5.15-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summaryThe filename of the patch is:
x86-mce-remove-noinstr-annotation-from-mce_setup.patch
and it can be found in the queue-5.15 subdirectory.If you, or anyone else, feels it should not be added to the stable tree, please let <[email protected]> know about it.
From
487d654db3edacc31dee86b10258cc740640fad8Mon Sep 17 00:00:00 2001
From: Borislav Petkov <[email protected]>
Date: Tue, 5 Oct 2021 19:54:47 +0200
Subject: x86/mce: Remove noinstr annotation frommce_setup()From: Borislav Petkov <[email protected]>
commit
487d654db3edacc31dee86b10258cc740640fad8upstream.Instead, sandwitch around the call which is done in noinstr context and mark the caller -
mce_gather_info()- as noinstr.Also, document what the whole instrumentation strategy with #MC is going to be in the future and where it all is supposed to be going to.
Quoted 6 lines
Signed-off-by Borislav Petkov <[email protected]>Signed-off-by Greg Kroah-Hartman <[email protected]>--- arch/x86/kernel/cpu/mce/core.c | 26 ++++++++++++++++++++------ 1 file changed, 20 insertions(+), 6 deletions(-)
Quoted 2 lines
I wonder how that can ever be stable material... or are you backporting something else and you need this?
I was trying to get rid of this build warning I see with 5.16:
vmlinux.o: warning: objtool: mce_setup()+0x22: call to memset() leaves .noinstr.text section vmlinux.o: warning: objtool: do_machine_check()+0x9b: call to mce_gather_info() leaves .noinstr.text section
But with this commit applied I now see this:
vmlinux.o: warning: objtool: mce_gather_info()+0x5f: call to v8086_mode.constprop.0() leaves .noinstr.text section vmlinux.o: warning: objtool: do_machine_check()+0x183: call to memset() leaves .noinstr.text section
So it didn't help that much.
Any hints on how to get rid of this? More patches in the series this one came from?
thanks,
greg k-h
Quoted 2 lines · Greg KH
Any hints on how to get rid of this? More patches in the series this one came from?
Unfortunately, a whole series:
https://lore.kernel.org/r/[email protected]
and the 0day bot guys recently managed to trigger another warning there, which means even more fixes, even to generic code.
So what that warning tells you is that you call into instrumentable context from non-instrumentable one. But that has relevance only when someone traces the MCE code - and up until now I haven't received a single sensible use case for why that would make any sense.
So long story short, you can safely ignore it and if someone complains, ask her/him about the use case first and CC me.
:-)
Signature · 4 lines
Regards/Gruss,
Boris.
SUSE Software Solutions Germany GmbH, GF: Ivo Totev, HRB 36809, AG NürnbergGreg KH
maintainerQuoted 16 lines · Borislav Petkov
Quoted 2 lines · Greg KH
Any hints on how to get rid of this? More patches in the series this one came from?
Unfortunately, a whole series:
https://lore.kernel.org/r/[email protected]
and the 0day bot guys recently managed to trigger another warning there, which means even more fixes, even to generic code.
So what that warning tells you is that you call into instrumentable context from non-instrumentable one. But that has relevance only when someone traces the MCE code - and up until now I haven't received a single sensible use case for why that would make any sense.
Quoted 4 lines
So long story short, you can safely ignore it and if someone complains, ask her/him about the use case first and CC me.
:-)
Ok, will just ignore it, 5.16.y should only be alive for a few months (4?) so it's not that big of a deal, I was just trying to ensure 0-warning builds were happening as it's easier to notice when I mess something up with the stable releases.
I'll go drop this commit now, thanks.
greg k-h