Skip to contentSkip to conversation

Patch "x86/mce: Remove noinstr annotation from mce_setup()" has been added to the 5.15-stable tree

DISCUSSION Greg KH 2 participants 3 messages Jan 13, 2022 2 messages not in the archive Stable branch

lore
Share & tools
lore

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

author maintainer
#2 lore raw
Quoted 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=summary

The 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 487d654db3edacc31dee86b10258cc740640fad8 Mon 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 from mce_setup()

From: Borislav Petkov <[email protected]>

commit 487d654db3edacc31dee86b10258cc740640fad8 upstream.

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
---
 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

#3 lore raw
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ürnberg
author maintainer
#4 lore raw
Quoted 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