From: Ingo Molnar <mingo@kernel.org>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Peter Zijlstra <a.p.zijlstra@chello.nl>,
Thomas Gleixner <tglx@linutronix.de>,
Borislav Petkov <bp@alien8.de>,
Andrew Morton <akpm@linux-foundation.org>
Subject: [PATCH] compiler.h: Move instrumentation_begin()/end() into new <linux/instrumentation.h> header
Date: Thu, 4 Jun 2020 09:19:21 +0200 [thread overview]
Message-ID: <20200604071921.GA1361070@gmail.com> (raw)
In-Reply-To: <CAHk-=wgmXOFyiu6jZ8Dj8OAU7c0T0q-6RLygKC2tMiNfL7MQjQ@mail.gmail.com>
* Linus Torvalds <torvalds@linux-foundation.org> wrote:
> On Mon, Jun 1, 2020 at 6:08 AM Ingo Molnar <mingo@kernel.org> wrote:
> >
> > include/linux/compiler.h | 53 +++++++++++++++++++++++
>
> I have pulled this, but do we really want to add this to a header file
> that is _so_ core that it gets included for basically every single
> file built?
>
> I don't even see those instrumentation_begin/end() things used
> anywhere right now.
>
> It seems excessive. That 53 lines is maybe not a lot, but it pushed
> that header file to over 12kB, and while it's mostly comments, it's
> extra IO and parsing basically for _every_ single file compiled in the
> kernel.
>
> For what appears to be absolutely zero upside right now, and I really
> don't see why this should be in such a core header file!
>
> I don't even see this as having anything at all to do with
> "compiler.h" in the first place.
>
> I really think we should think twice about making core header files
> bigger like this. No, we're nowhere the disaster that C++ project
> headers are, but tokenization and parsing is actually a pretty big
> part of the build costs (which may surprise some people who think it's
> all the fancy optimizations that cost a lot of CPU time).
Fully agreed - and I made the attached patch to address this.
The code got cleaner and better structured, but it didn't help much in
terms of inclusion count:
2616 total .o files
2447 <linux/types.h>
2436 <linux/compiler.h>
2404 <linux/bug.h>
The reason is that <linux/bug.h> is included almost everywhere as
well, and the instrumentation_begin()/end() annotations affect the
BUG*() and WARN*() primitives as well.
At least non-x86 would have less instrumentation related noise, for
now at least.
Thanks,
Ingo
==========================>
From: Ingo Molnar <mingo@kernel.org>
Date: Thu, 4 Jun 2020 08:36:22 +0200
Subject: [PATCH] compiler.h: Move instrumentation_begin()/end() into new <linux/instrumentation.h> header
Linus pointed out that compiler.h - which is a key header that gets included in every
single of the 28,000+ kernel files files being built - was unnecessarily bloated in:
655389666643: ("vmlinux.lds.h: Create section for protection against instrumentation")
Move these primitives into a new header: <linux/instrumentation.h>, and include that
header in context_tracking.h and x86/asm/bug.h, which makes use of it.
Reported-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
---
arch/x86/include/asm/bug.h | 1 +
include/linux/compiler.h | 53 -------------------------------------
include/linux/context_tracking.h | 2 ++
include/linux/instrumentation.h | 57 ++++++++++++++++++++++++++++++++++++++++
4 files changed, 60 insertions(+), 53 deletions(-)
diff --git a/arch/x86/include/asm/bug.h b/arch/x86/include/asm/bug.h
index facba9bc30ca..37e4480dba75 100644
--- a/arch/x86/include/asm/bug.h
+++ b/arch/x86/include/asm/bug.h
@@ -3,6 +3,7 @@
#define _ASM_X86_BUG_H
#include <linux/stringify.h>
+#include <linux/instrumentation.h>
/*
* Despite that some emulators terminate on UD2, we use it for WARN().
diff --git a/include/linux/compiler.h b/include/linux/compiler.h
index 6325d64e3c3b..448c91bf543b 100644
--- a/include/linux/compiler.h
+++ b/include/linux/compiler.h
@@ -120,65 +120,12 @@ void ftrace_likely_update(struct ftrace_likely_data *f, int val,
/* Annotate a C jump table to allow objtool to follow the code flow */
#define __annotate_jump_table __section(.rodata..c_jump_table)
-#ifdef CONFIG_DEBUG_ENTRY
-/* Begin/end of an instrumentation safe region */
-#define instrumentation_begin() ({ \
- asm volatile("%c0:\n\t" \
- ".pushsection .discard.instr_begin\n\t" \
- ".long %c0b - .\n\t" \
- ".popsection\n\t" : : "i" (__COUNTER__)); \
-})
-
-/*
- * Because instrumentation_{begin,end}() can nest, objtool validation considers
- * _begin() a +1 and _end() a -1 and computes a sum over the instructions.
- * When the value is greater than 0, we consider instrumentation allowed.
- *
- * There is a problem with code like:
- *
- * noinstr void foo()
- * {
- * instrumentation_begin();
- * ...
- * if (cond) {
- * instrumentation_begin();
- * ...
- * instrumentation_end();
- * }
- * bar();
- * instrumentation_end();
- * }
- *
- * If instrumentation_end() would be an empty label, like all the other
- * annotations, the inner _end(), which is at the end of a conditional block,
- * would land on the instruction after the block.
- *
- * If we then consider the sum of the !cond path, we'll see that the call to
- * bar() is with a 0-value, even though, we meant it to happen with a positive
- * value.
- *
- * To avoid this, have _end() be a NOP instruction, this ensures it will be
- * part of the condition block and does not escape.
- */
-#define instrumentation_end() ({ \
- asm volatile("%c0: nop\n\t" \
- ".pushsection .discard.instr_end\n\t" \
- ".long %c0b - .\n\t" \
- ".popsection\n\t" : : "i" (__COUNTER__)); \
-})
-#endif /* CONFIG_DEBUG_ENTRY */
-
#else
#define annotate_reachable()
#define annotate_unreachable()
#define __annotate_jump_table
#endif
-#ifndef instrumentation_begin
-#define instrumentation_begin() do { } while(0)
-#define instrumentation_end() do { } while(0)
-#endif
-
#ifndef ASM_UNREACHABLE
# define ASM_UNREACHABLE
#endif
diff --git a/include/linux/context_tracking.h b/include/linux/context_tracking.h
index 8cac62ee6add..ad6241c8003d 100644
--- a/include/linux/context_tracking.h
+++ b/include/linux/context_tracking.h
@@ -5,6 +5,8 @@
#include <linux/sched.h>
#include <linux/vtime.h>
#include <linux/context_tracking_state.h>
+#include <linux/instrumentation.h>
+
#include <asm/ptrace.h>
diff --git a/include/linux/instrumentation.h b/include/linux/instrumentation.h
new file mode 100644
index 000000000000..19cba99342c2
--- /dev/null
+++ b/include/linux/instrumentation.h
@@ -0,0 +1,57 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef __LINUX_INSTRUMENTATION_H
+#define __LINUX_INSTRUMENTATION_H
+
+#if defined(CONFIG_DEBUG_ENTRY) && defined(CONFIG_STACK_VALIDATION)
+
+/* Begin/end of an instrumentation safe region */
+#define instrumentation_begin() ({ \
+ asm volatile("%c0:\n\t" \
+ ".pushsection .discard.instr_begin\n\t" \
+ ".long %c0b - .\n\t" \
+ ".popsection\n\t" : : "i" (__COUNTER__)); \
+})
+
+/*
+ * Because instrumentation_{begin,end}() can nest, objtool validation considers
+ * _begin() a +1 and _end() a -1 and computes a sum over the instructions.
+ * When the value is greater than 0, we consider instrumentation allowed.
+ *
+ * There is a problem with code like:
+ *
+ * noinstr void foo()
+ * {
+ * instrumentation_begin();
+ * ...
+ * if (cond) {
+ * instrumentation_begin();
+ * ...
+ * instrumentation_end();
+ * }
+ * bar();
+ * instrumentation_end();
+ * }
+ *
+ * If instrumentation_end() would be an empty label, like all the other
+ * annotations, the inner _end(), which is at the end of a conditional block,
+ * would land on the instruction after the block.
+ *
+ * If we then consider the sum of the !cond path, we'll see that the call to
+ * bar() is with a 0-value, even though, we meant it to happen with a positive
+ * value.
+ *
+ * To avoid this, have _end() be a NOP instruction, this ensures it will be
+ * part of the condition block and does not escape.
+ */
+#define instrumentation_end() ({ \
+ asm volatile("%c0: nop\n\t" \
+ ".pushsection .discard.instr_end\n\t" \
+ ".long %c0b - .\n\t" \
+ ".popsection\n\t" : : "i" (__COUNTER__)); \
+})
+#else
+# define instrumentation_begin() do { } while(0)
+# define instrumentation_end() do { } while(0)
+#endif
+
+#endif /* __LINUX_INSTRUMENTATION_H */
next prev parent reply other threads:[~2020-06-04 7:19 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-06-01 13:08 [GIT PULL] kprobes updates for v5.8 Ingo Molnar
2020-06-01 19:56 ` Linus Torvalds
2020-06-04 7:19 ` Ingo Molnar [this message]
2020-06-04 8:19 ` [PATCH] compiler.h: Move instrumentation_begin()/end() into new <linux/instrumentation.h> header Ingo Molnar
2020-06-04 9:38 ` Peter Zijlstra
2020-06-05 14:35 ` Ingo Molnar
2020-07-24 12:02 ` [tip: core/headers] compiler.h: Move instrumentation_begin()/end() to " tip-bot2 for Ingo Molnar
2020-06-01 21:55 ` [GIT PULL] kprobes updates for v5.8 pr-tracker-bot
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=20200604071921.GA1361070@gmail.com \
--to=mingo@kernel.org \
--cc=a.p.zijlstra@chello.nl \
--cc=akpm@linux-foundation.org \
--cc=bp@alien8.de \
--cc=linux-kernel@vger.kernel.org \
--cc=tglx@linutronix.de \
--cc=torvalds@linux-foundation.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;
as well as URLs for NNTP newsgroup(s).