From: Borislav Petkov <bp@alien8.de>
To: Marco Elver <elver@google.com>
Cc: Tony Luck <tony.luck@intel.com>, Jakub Kicinski <kuba@kernel.org>,
Linus Torvalds <torvalds@linux-foundation.org>,
X86 ML <x86@kernel.org>, LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 0/3] x86/mce: Fix more noinstr fun
Date: Fri, 4 Feb 2022 15:48:40 +0100 [thread overview]
Message-ID: <Yf08yMZZDCtYMBVX@zn.tnic> (raw)
In-Reply-To: <CANpmjNOvf7z4BdPqrJH2iF0KnZmP58uUzSH0fFoc4VNg+2S=hw@mail.gmail.com>
On Fri, Feb 04, 2022 at 12:24:00PM +0100, Marco Elver wrote:
> I guess to solve noinstr "calling" something else the only solution is
> to make the other function noinstr as well, or __always_inline.
>
> Have you considered making some of these other functions 'noinstr' as
> well? I guess __always_inline works, esp. if there's just 1 caller.
> And by the looks of it you're getting a net .text reduction, so
Yeah, I started doing that and the savings were the persuasive
argument.
Even more so if the function has one caller only and gets inlined,
normally. I guess it doesn't get inlined when there's KASAN
instrumentation or so but I haven't verified it fully why.
Because even for oneliners like v8086_mode() which should get inlined
trivially, the compiler ends up doing this constprop thing - I guess
some constants folding optimization thing... it probably doesn't even
matter so much whether oneliners get inlined in KASAN-enabled builds so
I guess we might just as well force-inline them for the other configs.
> Acked-by: Marco Elver <elver@google.com>
Thx.
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
prev parent reply other threads:[~2022-02-04 14:48 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-02-04 8:30 [PATCH 0/3] x86/mce: Fix more noinstr fun Borislav Petkov
2022-02-04 8:30 ` [PATCH 1/3] cpumask: Add a x86-specific cpumask_clear_cpu() helper Borislav Petkov
2022-02-04 16:46 ` Luck, Tony
2022-02-04 18:04 ` Borislav Petkov
2022-02-13 10:59 ` [tip: locking/core] " tip-bot2 for Borislav Petkov
2022-02-04 8:30 ` [PATCH 2/3] x86/ptrace: Always inline v8086_mode() for instrumentation Borislav Petkov
2022-02-13 10:59 ` [tip: locking/core] " tip-bot2 for Borislav Petkov
2022-02-04 8:30 ` [PATCH 3/3] x86/mce: Use arch atomic and bit helpers Borislav Petkov
2022-02-14 10:03 ` [tip: ras/core] " tip-bot2 for Borislav Petkov
2022-02-04 11:24 ` [PATCH 0/3] x86/mce: Fix more noinstr fun Marco Elver
2022-02-04 14:48 ` Borislav Petkov [this message]
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=Yf08yMZZDCtYMBVX@zn.tnic \
--to=bp@alien8.de \
--cc=elver@google.com \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=tony.luck@intel.com \
--cc=torvalds@linux-foundation.org \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.