From: Andy Lutomirski <luto@kernel.org>
To: x86@kernel.org, linux-kernel@vger.kernel.org
Cc: "Brian Gerst" <brgerst@gmail.com>,
"Linus Torvalds" <torvalds@linux-foundation.org>,
"Borislav Petkov" <bp@alien8.de>,
"Frédéric Weisbecker" <fweisbec@gmail.com>,
"Peter Zijlstra" <peterz@infradead.org>,
"Andy Lutomirski" <luto@kernel.org>
Subject: [PATCH 1/4] x86/entry/64: Fix irqflag tracing wrt context tracking
Date: Fri, 6 Nov 2015 15:12:43 -0800 [thread overview]
Message-ID: <f3b6b3003f7a2d3304763394160dc7e32ff70d6c.1446849780.git.luto@kernel.org> (raw)
In-Reply-To: <cover.1446849780.git.luto@kernel.org>
In-Reply-To: <cover.1446849780.git.luto@kernel.org>
Paolo pointed out that enter_from_user_mode could be called while
irqflags were traced as though IRQs were on.
In principle, this could confuse lockdep. It doesn't cause any
problems that I've seen in any configuration, but if I build with
CONFIG_DEBUG_LOCKDEP=y, enable a nohz_full CPU, and add code like:
if (irqs_disabled()) {
spin_lock(&something);
spin_unlock(&something);
}
to the top of enter_from_user_mode, then lockdep will complain
without this fix. It seems that lockdep's irqflags sanity checks
are too weak to detect this bug without forcing the issue.
This patch adds one byte to normal kernels, and it's IMO a bit ugly.
I haven't spotted a better way to do this yet, though. The issue is
that we can't do TRACE_IRQS_OFF until after SWAPGS (if needed), but
we're also supposed to do it before calling C code.
An alternative approach would be to call trace_hardirqs_off in
enter_from_user_mode. That would be less code and would not bloat
normal kernels at all, but it would be harder to see how the code
worked.
Signed-off-by: Andy Lutomirski <luto@kernel.org>
---
arch/x86/entry/entry_64.S | 11 ++++++++++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/arch/x86/entry/entry_64.S b/arch/x86/entry/entry_64.S
index 53616ca03244..f585df24ab3d 100644
--- a/arch/x86/entry/entry_64.S
+++ b/arch/x86/entry/entry_64.S
@@ -509,6 +509,14 @@ END(irq_entries_start)
* tracking that we're in kernel mode.
*/
SWAPGS
+
+ /*
+ * IRQs are off. NB: this trace call is duplicated. That's
+ * okay -- it's idempotent and it's irrelevant for performance as
+ * it's a no-op unless CONFIG_DEBUG_LOCKDEP=y.
+ */
+ TRACE_IRQS_OFF
+
#ifdef CONFIG_CONTEXT_TRACKING
call enter_from_user_mode
#endif
@@ -1049,12 +1057,13 @@ ENTRY(error_entry)
SWAPGS
.Lerror_entry_from_usermode_after_swapgs:
+ TRACE_IRQS_OFF
#ifdef CONFIG_CONTEXT_TRACKING
call enter_from_user_mode
#endif
+ ret
.Lerror_entry_done:
-
TRACE_IRQS_OFF
ret
--
2.4.3
next prev parent reply other threads:[~2015-11-06 23:12 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-11-06 23:12 [PATCH 0/4] x86 entry stuff, maybe for 4.4 Andy Lutomirski
2015-11-06 23:12 ` Andy Lutomirski [this message]
2015-11-07 9:59 ` [PATCH 1/4] x86/entry/64: Fix irqflag tracing wrt context tracking Thomas Gleixner
2015-11-07 11:18 ` Borislav Petkov
2015-11-09 4:20 ` Andy Lutomirski
2015-11-06 23:12 ` [PATCH 2/4] context_tracking: Switch to new static_branch API Andy Lutomirski
2015-11-07 9:59 ` Thomas Gleixner
2015-11-06 23:12 ` [PATCH 3/4] x86/asm: Add asm macros for static keys/jump labels Andy Lutomirski
2015-11-07 11:20 ` Thomas Gleixner
2015-11-07 16:49 ` Andy Lutomirski
2015-11-07 16:58 ` Thomas Gleixner
2015-11-07 17:05 ` Andy Lutomirski
2015-11-07 17:08 ` Thomas Gleixner
2015-11-07 18:16 ` Andy Lutomirski
2015-11-09 9:48 ` Peter Zijlstra
2015-11-08 16:16 ` Andy Lutomirski
2015-11-06 23:12 ` [PATCH 4/4] x86/entry/64: Bypass enter_from_user_mode on non-context-tracking boots Andy Lutomirski
2015-11-09 8:52 ` Ingo Molnar
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=f3b6b3003f7a2d3304763394160dc7e32ff70d6c.1446849780.git.luto@kernel.org \
--to=luto@kernel.org \
--cc=bp@alien8.de \
--cc=brgerst@gmail.com \
--cc=fweisbec@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=peterz@infradead.org \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®