linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Peter Zijlstra <peterz@infradead.org>
To: tglx@linutronix.de
Cc: x86@kernel.org, elver@google.com, paulmck@kernel.org,
	kasan-dev@googlegroups.com, linux-kernel@vger.kernel.org,
	peterz@infradead.org, will@kernel.org, dvyukov@google.com,
	glider@google.com, andreyknvl@google.com
Subject: [PATCH 6/9] x86/entry: Re-order #DB handler to avoid *SAN instrumentation
Date: Wed, 03 Jun 2020 13:40:20 +0200	[thread overview]
Message-ID: <20200603114052.127756554@infradead.org> (raw)
In-Reply-To: 20200603114014.152292216@infradead.org

vmlinux.o: warning: objtool: exc_debug()+0xbb: call to clear_ti_thread_flag.constprop.0() leaves .noinstr.text section
vmlinux.o: warning: objtool: noist_exc_debug()+0x55: call to clear_ti_thread_flag.constprop.0() leaves .noinstr.text section

Rework things so that handle_debug() looses the noinstr and move the
clear_thread_flag() into that.

Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
---
 arch/x86/kernel/traps.c |   55 +++++++++++++++++++++++-------------------------
 1 file changed, 27 insertions(+), 28 deletions(-)

--- a/arch/x86/kernel/traps.c
+++ b/arch/x86/kernel/traps.c
@@ -775,26 +775,44 @@ static __always_inline void debug_exit(u
  *
  * May run on IST stack.
  */
-static void noinstr handle_debug(struct pt_regs *regs, unsigned long dr6,
-				 bool user_icebp)
+static void handle_debug(struct pt_regs *regs, unsigned long dr6, bool user)
 {
 	struct task_struct *tsk = current;
+	bool user_icebp;
 	int si_code;
 
+	/*
+	 * The SDM says "The processor clears the BTF flag when it
+	 * generates a debug exception."  Clear TIF_BLOCKSTEP to keep
+	 * TIF_BLOCKSTEP in sync with the hardware BTF flag.
+	 */
+	clear_thread_flag(TIF_BLOCKSTEP);
+
+	/*
+	 * If DR6 is zero, no point in trying to handle it. The kernel is
+	 * not using INT1.
+	 */
+	if (!user && !dr6)
+		return;
+
+	/*
+	 * If dr6 has no reason to give us about the origin of this trap,
+	 * then it's very likely the result of an icebp/int01 trap.
+	 * User wants a sigtrap for that.
+	 */
+	user_icebp = user && !dr6;
+
 	/* Store the virtualized DR6 value */
 	tsk->thread.debugreg6 = dr6;
 
-	instrumentation_begin();
 #ifdef CONFIG_KPROBES
 	if (kprobe_debug_handler(regs)) {
-		instrumentation_end();
 		return;
 	}
 #endif
 
 	if (notify_die(DIE_DEBUG, "debug", regs, (long)&dr6, 0,
 		       SIGTRAP) == NOTIFY_STOP) {
-		instrumentation_end();
 		return;
 	}
 
@@ -825,7 +843,6 @@ static void noinstr handle_debug(struct
 
 out:
 	cond_local_irq_disable(regs);
-	instrumentation_end();
 }
 
 static __always_inline void exc_debug_kernel(struct pt_regs *regs,
@@ -834,14 +851,6 @@ static __always_inline void exc_debug_ke
 	nmi_enter();
 	instrumentation_begin();
 	trace_hardirqs_off_finish();
-	instrumentation_end();
-
-	/*
-	 * The SDM says "The processor clears the BTF flag when it
-	 * generates a debug exception."  Clear TIF_BLOCKSTEP to keep
-	 * TIF_BLOCKSTEP in sync with the hardware BTF flag.
-	 */
-	clear_thread_flag(TIF_BLOCKSTEP);
 
 	/*
 	 * Catch SYSENTER with TF set and clear DR_STEP. If this hit a
@@ -850,14 +859,8 @@ static __always_inline void exc_debug_ke
 	if ((dr6 & DR_STEP) && is_sysenter_singlestep(regs))
 		dr6 &= ~DR_STEP;
 
-	/*
-	 * If DR6 is zero, no point in trying to handle it. The kernel is
-	 * not using INT1.
-	 */
-	if (dr6)
-		handle_debug(regs, dr6, false);
+	handle_debug(regs, dr6, false);
 
-	instrumentation_begin();
 	if (regs->flags & X86_EFLAGS_IF)
 		trace_hardirqs_on_prepare();
 	instrumentation_end();
@@ -868,14 +871,10 @@ static __always_inline void exc_debug_us
 					   unsigned long dr6)
 {
 	idtentry_enter_user(regs);
-	clear_thread_flag(TIF_BLOCKSTEP);
+	instrumentation_begin();
 
-	/*
-	 * If dr6 has no reason to give us about the origin of this trap,
-	 * then it's very likely the result of an icebp/int01 trap.
-	 * User wants a sigtrap for that.
-	 */
-	handle_debug(regs, dr6, !dr6);
+	handle_debug(regs, dr6, true);
+	instrumentation_end();
 	idtentry_exit_user(regs);
 }
 



  parent reply	other threads:[~2020-06-03 11:42 UTC|newest]

Thread overview: 51+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-06-03 11:40 [PATCH 0/9] x86/entry fixes Peter Zijlstra
2020-06-03 11:40 ` [PATCH 1/9] x86/entry: Fix irq_exit() Peter Zijlstra
2020-06-03 11:40 ` [PATCH 2/9] rcu: Fixup noinstr warnings Peter Zijlstra
2020-06-03 16:46   ` Paul E. McKenney
2020-06-03 17:13     ` Peter Zijlstra
2020-06-04  3:34       ` Paul E. McKenney
2020-06-04  6:02         ` Marco Elver
2020-06-04 14:14           ` Paul E. McKenney
2020-06-04  8:05         ` Peter Zijlstra
2020-06-04 14:17           ` Paul E. McKenney
2020-06-15 15:30     ` Peter Zijlstra
2020-06-15 15:52       ` Paul E. McKenney
2020-06-15 16:06         ` Peter Zijlstra
2020-06-15 15:49   ` Peter Zijlstra
2020-06-15 15:55     ` Peter Zijlstra
2020-06-15 16:24       ` Peter Zijlstra
2020-06-15 17:14         ` Paul E. McKenney
2020-06-15 18:33           ` Peter Zijlstra
2020-06-15 18:59             ` Paul E. McKenney
2020-06-15 20:00           ` Paul E. McKenney
2020-06-19 22:15           ` Paul E. McKenney
2020-06-23 20:46             ` Peter Zijlstra
2020-06-23 21:44               ` Paul E. McKenney
2020-06-24  7:52                 ` Peter Zijlstra
2020-06-24 13:03                   ` Paul E. McKenney
2020-06-03 11:40 ` [PATCH 3/9] x86/entry: __always_inline debugreg for noinstr Peter Zijlstra
2020-06-03 17:50   ` [tip: x86/entry] " tip-bot2 for Peter Zijlstra
2020-06-03 11:40 ` [PATCH 4/9] x86/entry: __always_inline irqflags " Peter Zijlstra
2020-06-03 17:50   ` [tip: x86/entry] " tip-bot2 for Peter Zijlstra
2020-06-03 11:40 ` [PATCH 5/9] x86/entry: __always_inline arch_atomic_* " Peter Zijlstra
2020-06-03 17:50   ` [tip: x86/entry] " tip-bot2 for Peter Zijlstra
2020-06-03 11:40 ` Peter Zijlstra [this message]
2020-06-03 17:50   ` [tip: x86/entry] x86/entry: Re-order #DB handler to avoid *SAN instrumentation tip-bot2 for Peter Zijlstra
2020-06-03 11:40 ` [PATCH 7/9] lockdep: __always_inline more for noinstr Peter Zijlstra
2020-06-03 17:50   ` [tip: x86/entry] " tip-bot2 for Peter Zijlstra
2020-06-03 11:40 ` [PATCH 8/9] x86/entry: __always_inline CR2 " Peter Zijlstra
2020-06-03 17:50   ` [tip: x86/entry] " tip-bot2 for Peter Zijlstra
2020-06-03 11:40 ` [PATCH 9/9] x86/entry, cpumask: Provide non-instrumented variant of cpu_is_offline() Peter Zijlstra
2020-06-03 17:50   ` [tip: x86/entry] " tip-bot2 for Peter Zijlstra
2020-06-03 12:00 ` [PATCH 0/9] x86/entry fixes Peter Zijlstra
2020-06-03 12:08   ` Peter Zijlstra
2020-06-03 12:08     ` Marco Elver
2020-06-03 12:18       ` Peter Zijlstra
2020-06-03 13:32         ` Marco Elver
2020-06-03 14:47           ` Marco Elver
2020-06-03 16:07             ` Peter Zijlstra
2020-06-03 17:26               ` Marco Elver
2020-06-03 18:16               ` Peter Zijlstra
2020-06-03 19:10                 ` Marco Elver
2020-06-04  6:00                   ` Marco Elver
2020-06-04  9:52                     ` Marco Elver

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=20200603114052.127756554@infradead.org \
    --to=peterz@infradead.org \
    --cc=andreyknvl@google.com \
    --cc=dvyukov@google.com \
    --cc=elver@google.com \
    --cc=glider@google.com \
    --cc=kasan-dev@googlegroups.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=paulmck@kernel.org \
    --cc=tglx@linutronix.de \
    --cc=will@kernel.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 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).