From: Frederic Weisbecker <fweisbec@gmail.com>
To: Andy Lutomirski <luto@kernel.org>
Cc: x86@kernel.org, Sasha Levin <sasha.levin@oracle.com>,
Brian Gerst <brgerst@gmail.com>,
Denys Vlasenko <dvlasenk@redhat.com>,
linux-kernel@vger.kernel.org, Oleg Nesterov <oleg@redhat.com>,
Borislav Petkov <bp@alien8.de>
Subject: Re: [PATCH] x86/traps: Weaken context tracking entry assertions
Date: Fri, 21 Aug 2015 15:24:39 +0200 [thread overview]
Message-ID: <20150821132438.GB3362@lerouge> (raw)
In-Reply-To: <c81faf3916346c0e04346c441392974f49cd7184.1440133286.git.luto@kernel.org>
On Thu, Aug 20, 2015 at 10:03:21PM -0700, Andy Lutomirski wrote:
> We were asserting that we were all the way in CONTEXT_KERNEL when
> exception handlers were called. While having this be true is, I
> think, a nice goal (or maybe a variant in which we assert that we're
> in CONTEXT_KERNEL or some new IRQ context), we're not quite there.
>
> In particular, if an IRQ interrupts the SYSCALL prologue and the IRQ
> handler in turn causes an exception, the exception entry will be
> called in RCU IRQ mode but with CONTEXT_USER.
>
> This is okay (nothing goes wrong), but until we fix up the SYSCALL
> prologue, we need to avoid warning.
We can avoid interrupts before the context tracking call but we'll
never be able to remove all possibility for exceptions. I don't think
we can assume that without making context tracking more fragile.
>
> Signed-off-by: Andy Lutomirski <luto@kernel.org>
ACK!
Thanks!
We can indeed definetly trigger an exception in the kernel entry code
(syscall, exception, irq) before the user_exit() call and that
would break the checks. We can fix that later with context tracking
calls on exception entry code. I still think an exception slow path
based on static keys is the best way to go there.
> ---
> arch/x86/kernel/traps.c | 18 +++++++++---------
> 1 file changed, 9 insertions(+), 9 deletions(-)
>
> diff --git a/arch/x86/kernel/traps.c b/arch/x86/kernel/traps.c
> index 86a82eafb96f..45e8d9891fa3 100644
> --- a/arch/x86/kernel/traps.c
> +++ b/arch/x86/kernel/traps.c
> @@ -112,7 +112,7 @@ static inline void preempt_conditional_cli(struct pt_regs *regs)
> void ist_enter(struct pt_regs *regs)
> {
> if (user_mode(regs)) {
> - CT_WARN_ON(ct_state() != CONTEXT_KERNEL);
> + rcu_lockdep_assert(rcu_is_watching(), "entry code didn't wake RCU");
> } else {
> /*
> * We might have interrupted pretty much anything. In
> @@ -282,7 +282,7 @@ static void do_error_trap(struct pt_regs *regs, long error_code, char *str,
> {
> siginfo_t info;
>
> - CT_WARN_ON(ct_state() != CONTEXT_KERNEL);
> + rcu_lockdep_assert(rcu_is_watching(), "entry code didn't wake RCU");
>
> if (notify_die(DIE_TRAP, str, regs, error_code, trapnr, signr) !=
> NOTIFY_STOP) {
> @@ -364,7 +364,7 @@ dotraplinkage void do_bounds(struct pt_regs *regs, long error_code)
> const struct bndcsr *bndcsr;
> siginfo_t *info;
>
> - CT_WARN_ON(ct_state() != CONTEXT_KERNEL);
> + rcu_lockdep_assert(rcu_is_watching(), "entry code didn't wake RCU");
> if (notify_die(DIE_TRAP, "bounds", regs, error_code,
> X86_TRAP_BR, SIGSEGV) == NOTIFY_STOP)
> return;
> @@ -442,7 +442,7 @@ do_general_protection(struct pt_regs *regs, long error_code)
> {
> struct task_struct *tsk;
>
> - CT_WARN_ON(ct_state() != CONTEXT_KERNEL);
> + rcu_lockdep_assert(rcu_is_watching(), "entry code didn't wake RCU");
> conditional_sti(regs);
>
> if (v8086_mode(regs)) {
> @@ -496,7 +496,7 @@ dotraplinkage void notrace do_int3(struct pt_regs *regs, long error_code)
> return;
>
> ist_enter(regs);
> - CT_WARN_ON(ct_state() != CONTEXT_KERNEL);
> + rcu_lockdep_assert(rcu_is_watching(), "entry code didn't wake RCU");
> #ifdef CONFIG_KGDB_LOW_LEVEL_TRAP
> if (kgdb_ll_trap(DIE_INT3, "int3", regs, error_code, X86_TRAP_BP,
> SIGTRAP) == NOTIFY_STOP)
> @@ -729,14 +729,14 @@ static void math_error(struct pt_regs *regs, int error_code, int trapnr)
>
> dotraplinkage void do_coprocessor_error(struct pt_regs *regs, long error_code)
> {
> - CT_WARN_ON(ct_state() != CONTEXT_KERNEL);
> + rcu_lockdep_assert(rcu_is_watching(), "entry code didn't wake RCU");
> math_error(regs, error_code, X86_TRAP_MF);
> }
>
> dotraplinkage void
> do_simd_coprocessor_error(struct pt_regs *regs, long error_code)
> {
> - CT_WARN_ON(ct_state() != CONTEXT_KERNEL);
> + rcu_lockdep_assert(rcu_is_watching(), "entry code didn't wake RCU");
> math_error(regs, error_code, X86_TRAP_XF);
> }
>
> @@ -749,7 +749,7 @@ do_spurious_interrupt_bug(struct pt_regs *regs, long error_code)
> dotraplinkage void
> do_device_not_available(struct pt_regs *regs, long error_code)
> {
> - CT_WARN_ON(ct_state() != CONTEXT_KERNEL);
> + rcu_lockdep_assert(rcu_is_watching(), "entry code didn't wake RCU");
> BUG_ON(use_eager_fpu());
>
> #ifdef CONFIG_MATH_EMULATION
> @@ -775,7 +775,7 @@ dotraplinkage void do_iret_error(struct pt_regs *regs, long error_code)
> {
> siginfo_t info;
>
> - CT_WARN_ON(ct_state() != CONTEXT_KERNEL);
> + rcu_lockdep_assert(rcu_is_watching(), "entry code didn't wake RCU");
> local_irq_enable();
>
> info.si_signo = SIGILL;
> --
> 2.4.3
>
next prev parent reply other threads:[~2015-08-21 13:24 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-08-21 5:03 Andy Lutomirski
2015-08-21 6:23 ` Ingo Molnar
2015-08-21 13:38 ` Frederic Weisbecker
2015-08-21 14:39 ` Andy Lutomirski
2015-08-21 13:24 ` Frederic Weisbecker [this message]
2015-08-22 13:57 ` [tip:core/core] " tip-bot for Andy Lutomirski
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=20150821132438.GB3362@lerouge \
--to=fweisbec@gmail.com \
--cc=bp@alien8.de \
--cc=brgerst@gmail.com \
--cc=dvlasenk@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@kernel.org \
--cc=oleg@redhat.com \
--cc=sasha.levin@oracle.com \
--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®