[GIT PULL] kprobes updates for v5.8

[GIT PULL] kprobes updates for v5.8

[Ingo Molnar]

Linus,

Please pull the latest core/kprobes git tree from:

   git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git core-kprobes-2020-06-01

   # HEAD: 66e9b0717102507e64f638790eaece88765cc9e5 kprobes: Prevent probes in .noinstr.text section

Various kprobes updates, mostly centered around cleaning up the no-instrumentation
logic, instead of the current per debug facility blacklist, use the more generic
.noinstr.text approach, combined with a 'noinstr' marker for functions.

Also add instrumentation_begin()/end() to better manage the exact place in entry
code where instrumentation may be used.

Also add a kprobes blacklist for modules.

Signed-off-by: Ingo Molnar <mingo@kernel.org>
 Thanks,

	Ingo

------------------>
Masami Hiramatsu (4):
      kprobes: Lock kprobe_mutex while showing kprobe_blacklist
      kprobes: Support __kprobes blacklist in modules
      kprobes: Support NOKPROBE_SYMBOL() in modules
      samples/kprobes: Add __kprobes and NOKPROBE_SYMBOL() for handlers.

Thomas Gleixner (2):
      vmlinux.lds.h: Create section for protection against instrumentation
      kprobes: Prevent probes in .noinstr.text section


 arch/powerpc/kernel/vmlinux.lds.S   |  1 +
 include/asm-generic/sections.h      |  3 ++
 include/asm-generic/vmlinux.lds.h   | 10 +++++
 include/linux/compiler.h            | 53 +++++++++++++++++++++++
 include/linux/compiler_types.h      |  4 ++
 include/linux/module.h              |  8 ++++
 kernel/kprobes.c                    | 85 ++++++++++++++++++++++++++++++++++++-
 kernel/module.c                     | 10 +++++
 samples/kprobes/kprobe_example.c    |  6 ++-
 samples/kprobes/kretprobe_example.c |  2 +
 scripts/mod/modpost.c               |  2 +-
 11 files changed, 180 insertions(+), 4 deletions(-)

Re: [GIT PULL] kprobes updates for v5.8

[Linus Torvalds]

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

                  Linus

[PATCH] compiler.h: Move instrumentation_begin()/end() into new <linux/instrumentation.h> header

[Ingo Molnar]

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

Re: [PATCH] compiler.h: Move instrumentation_begin()/end() into new <linux/instrumentation.h> header

[Ingo Molnar]

* Ingo Molnar <mingo@kernel.org> wrote:

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

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

The tested v2 version of the patch also needed the include in 
asm-generic/bug.h (see the fix attached below), because for 
completeness the generic version was annotated as well - even though 
only x86 has objtool support for now.

The readability improvement is real though.

Thanks,

	Ingo


diff --git a/include/asm-generic/bug.h b/include/asm-generic/bug.h
index 384b5c835ced..c43b5906e0dc 100644
--- a/include/asm-generic/bug.h
+++ b/include/asm-generic/bug.h
@@ -3,6 +3,7 @@
 #define _ASM_GENERIC_BUG_H
 
 #include <linux/compiler.h>
+#include <linux/instrumentation.h>
 
 #define CUT_HERE		"------------[ cut here ]------------\n"
 

Re: [PATCH] compiler.h: Move instrumentation_begin()/end() into new <linux/instrumentation.h> header

[Peter Zijlstra]

On Thu, Jun 04, 2020 at 10:19:28AM +0200, Ingo Molnar wrote:
> The tested v2 version of the patch also needed the include in 
> asm-generic/bug.h (see the fix attached below), because for 
> completeness the generic version was annotated as well - even though 
> only x86 has objtool support for now.

x86/asm/bug.h includes asm-generic/bug.h.

x86 uses the generic bug infrastructure.

Re: [PATCH] compiler.h: Move instrumentation_begin()/end() into new <linux/instrumentation.h> header

[Ingo Molnar]

* Peter Zijlstra <peterz@infradead.org> wrote:

> On Thu, Jun 04, 2020 at 10:19:28AM +0200, Ingo Molnar wrote:
> > The tested v2 version of the patch also needed the include in 
> > asm-generic/bug.h (see the fix attached below), because for 
> > completeness the generic version was annotated as well - even though 
> > only x86 has objtool support for now.
> 
> x86/asm/bug.h includes asm-generic/bug.h.
> 
> x86 uses the generic bug infrastructure.

Yes, indeed. No change to the patch required (other than the 
changelog), both asm-generic/bug.h and x86/asm/bug.h make use of 
instrumentation_begin()/end(), so they both need the #include.

Thanks,

	Ingo

[tip: core/headers] compiler.h: Move instrumentation_begin()/end() to new <linux/instrumentation.h> header

[tip-bot2 for Ingo Molnar]

The following commit has been merged into the core/headers branch of tip:

Commit-ID:     d19e789f068b3d633cbac430764962f404198022
Gitweb:        https://git.kernel.org/tip/d19e789f068b3d633cbac430764962f404198022
Author:        Ingo Molnar <mingo@kernel.org>
AuthorDate:    Fri, 24 Jul 2020 13:50:25 +02:00
Committer:     Ingo Molnar <mingo@kernel.org>
CommitterDate: Fri, 24 Jul 2020 13:56:23 +02:00

compiler.h: Move instrumentation_begin()/end() to new <linux/instrumentation.h> header

Linus pointed out that compiler.h - which is a key header that gets included in every
single one of the 28,000+ kernel files during a kernel build - was bloated in:

  655389666643: ("vmlinux.lds.h: Create section for protection against instrumentation")

Linus noted:

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

Move these primitives into a new header: <linux/instrumentation.h>, and include that
header in the headers that make use of it.

Unfortunately one of these headers is asm-generic/bug.h, which does get included
in a lot of places, similarly to compiler.h. So the de-bloating effect isn't as
good as we'd like it to be - but at least the interfaces are defined separately.

No change to functionality intended.

Reported-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Link: https://lore.kernel.org/r/20200604071921.GA1361070@gmail.com
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Peter Zijlstra <peterz@infradead.org>
---
 arch/x86/include/asm/bug.h       |  1 +-
 include/asm-generic/bug.h        |  1 +-
 include/linux/compiler.h         | 53 +-----------------------------
 include/linux/context_tracking.h |  2 +-
 include/linux/instrumentation.h  | 57 +++++++++++++++++++++++++++++++-
 5 files changed, 61 insertions(+), 53 deletions(-)
 create mode 100644 include/linux/instrumentation.h

diff --git a/arch/x86/include/asm/bug.h b/arch/x86/include/asm/bug.h
index 0281895..297fa12 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/asm-generic/bug.h b/include/asm-generic/bug.h
index c94e33a..18b0f4e 100644
--- a/include/asm-generic/bug.h
+++ b/include/asm-generic/bug.h
@@ -3,6 +3,7 @@
 #define _ASM_GENERIC_BUG_H
 
 #include <linux/compiler.h>
+#include <linux/instrumentation.h>
 
 #define CUT_HERE		"------------[ cut here ]------------\n"
 
diff --git a/include/linux/compiler.h b/include/linux/compiler.h
index 204e768..681894b 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: nop\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 981b880..d53cd33 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 0000000..93e2ad6
--- /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: nop\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 */

Re: [GIT PULL] kprobes updates for v5.8

[pr-tracker-bot]

The pull request you sent on Mon, 1 Jun 2020 15:08:06 +0200:

> git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git core-kprobes-2020-06-01

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/0bd957eb11cfeef23fcc240edde6dfe431731e69

Thank you!

-- 
Deet-doot-dot, I am a bot.
https://korg.wiki.kernel.org/userdoc/prtracker