linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Andy Lutomirski <luto@amacapital.net>
To: "Luck, Tony" <tony.luck@intel.com>
Cc: Borislav Petkov <bp@alien8.de>, "x86@kernel.org" <x86@kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Peter Zijlstra <peterz@infradead.org>,
	Oleg Nesterov <oleg@redhat.com>, Andi Kleen <andi@firstfloor.org>
Subject: Re: [RFC PATCH] x86, entry: Switch stacks on a paranoid entry from userspace
Date: Tue, 11 Nov 2014 14:15:08 -0800	[thread overview]
Message-ID: <CALCETrUr8pjC40O_66dDUovEreXqBEEL3bHt7R3ciZ+oD8qW=g@mail.gmail.com> (raw)
In-Reply-To: <3908561D78D1C84285E8C5FCA982C28F32929962@ORSMSX114.amr.corp.intel.com>

On Tue, Nov 11, 2014 at 2:00 PM, Luck, Tony <tony.luck@intel.com> wrote:
> So here is the flow:
>
> 1) A machine check happens - it is (currently) broadcast to all logical cpus on all sockets
>
> 2) First cpu to execute "order = atomic_inc_return(&mce_callin);" in mce_start() gets to be the "monarch" and directs things during the handler.

This is a bit funky, since any number of #MCs might be delivered in
process context, and any one of them, or none of them, might win the
election.  Can this be made to not matter, or can the actual faulting
CPU be made to win the election?

>
> 3) Every cpu gets to scan all the machine check banks to see what happened. If the error was a fatal one we are going to panic - this isn't the interesting case.
>
> 4) There are two kinds of recoverable error
> 4a) Ones not in execution context (SRAO = Software Recoverable Action Optional) -  these also aren't very interesting - save the address in a NMI safe ring buffer to process later
> 4b) In execution context (SRAR = Software Recoverable Action Required) - this is where we need to do some real work to convert from the physical address logged to the list of affected processes.
>
> Now when we get to step 4b - we need to let all the other processors return from the machine check handler (they may have been interrupted in kernel context and could hold locks that we need).
>
> We also need to clear the MSR MCG_STATUS (on each logical cpu) to indicate we are done with this machine check.
>
>
> Andy - with your RFC patch - can we just make the bottom end of do_machine_check() look like this:
>
>         /* collected everything we need from banks - re-enable machine check on all cpus */
>         mce_wrmsrl(MSR_IA32_MCG_STATUS, 0);
>
>         if (we are *not* the thread with the SRAR error)
>                 return;
>
>         /* do all the things that were previously in mce_notify_process() here */
> }

That's the intent.

>
> and if we do this - what happens if we get another machine check while we are in the "do all the things" bit?
>

Is it the case that another #MC can't happen until you clear IA32_MCG_STATUS?

In any event, this should be no more or less safe than the previous
approach of doing the main part of #MC handling, then switching
stacks, then handling the rest in user context.  But you might be able
to get away with waiting to clear IA32_MCG_STATUS until after you're
done, as long as you don't let yourself be preempted.

What are the semantics of #MC nesting and masking, anyway?  Last time
I looked at the SDM, I couldn't figure it out.

--Andy

  reply	other threads:[~2014-11-11 22:15 UTC|newest]

Thread overview: 63+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-11-11 20:56 [RFC PATCH] x86, entry: Switch stacks on a paranoid entry from userspace Andy Lutomirski
2014-11-11 21:36 ` Borislav Petkov
2014-11-11 22:00   ` Luck, Tony
2014-11-11 22:15     ` Andy Lutomirski [this message]
2014-11-11 22:12   ` Andy Lutomirski
2014-11-11 22:33     ` Borislav Petkov
2014-11-11 22:40       ` Andy Lutomirski
2014-11-11 23:09         ` Borislav Petkov
2014-11-11 23:21           ` Andy Lutomirski
2014-11-12  0:22             ` Luck, Tony
2014-11-12  0:40               ` Andy Lutomirski
2014-11-12  1:06                 ` Luck, Tony
2014-11-12  2:01                   ` Andy Lutomirski
2014-11-12  2:06                   ` Tony Luck
2014-11-12 10:30                     ` Borislav Petkov
2014-11-12 15:48                       ` Andy Lutomirski
2014-11-12 16:22                         ` Borislav Petkov
2014-11-12 17:17                           ` Luck, Tony
2014-11-12 17:30                             ` Borislav Petkov
2014-11-13 18:04                           ` Borislav Petkov
2014-11-14 21:56                             ` Luck, Tony
2014-11-14 22:07                               ` Andy Lutomirski
2014-11-17 18:50                               ` Borislav Petkov
2014-11-17 19:57                                 ` Andy Lutomirski
2014-11-17 20:03                                   ` Borislav Petkov
2014-11-17 20:05                                     ` Andy Lutomirski
2014-11-17 21:55                                       ` Luck, Tony
2014-11-17 22:26                                         ` Andy Lutomirski
2014-11-17 23:16                                           ` Luck, Tony
2014-11-18  0:05                                             ` Andy Lutomirski
2014-11-18  0:22                                               ` Luck, Tony
2014-11-18  0:55                                                 ` Andy Lutomirski
2014-11-18 18:30                                                   ` Luck, Tony
2014-11-18 23:04                                                     ` Andy Lutomirski
2014-11-18 23:26                                                       ` Luck, Tony
2014-11-18 16:12                                       ` Borislav Petkov
2014-11-12 22:00 ` Oleg Nesterov
2014-11-12 23:17   ` Andy Lutomirski
2014-11-12 23:41     ` Luck, Tony
2014-11-13  0:02       ` Andy Lutomirski
2014-11-13  0:31         ` Luck, Tony
2014-11-13  1:34           ` Andy Lutomirski
2014-11-13  3:03           ` Andy Lutomirski
2014-11-13 18:43             ` Luck, Tony
2014-11-13 22:23               ` Andy Lutomirski
2014-11-13 22:25                 ` Andy Lutomirski
2014-11-13 22:33                 ` Luck, Tony
2014-11-13 22:47                   ` Andy Lutomirski
2014-11-13 23:13                     ` Andy Lutomirski
2014-11-14  0:50                       ` Andy Lutomirski
2014-11-14  1:20                         ` Luck, Tony
2014-11-14  1:36                           ` Andy Lutomirski
2014-11-14 17:49                         ` Luck, Tony
2014-11-14 19:10                           ` Andy Lutomirski
2014-11-14 19:37                             ` Luck, Tony
2014-11-14 18:27                         ` Luck, Tony
2014-11-14 10:34             ` Borislav Petkov
2014-11-14 17:18               ` Andy Lutomirski
2014-11-14 17:24                 ` Borislav Petkov
2014-11-14 17:26                   ` Andy Lutomirski
2014-11-14 18:53                     ` Borislav Petkov
2014-11-13 10:59           ` Borislav Petkov
2014-11-13 21:23             ` Borislav Petkov

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='CALCETrUr8pjC40O_66dDUovEreXqBEEL3bHt7R3ciZ+oD8qW=g@mail.gmail.com' \
    --to=luto@amacapital.net \
    --cc=andi@firstfloor.org \
    --cc=bp@alien8.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=oleg@redhat.com \
    --cc=peterz@infradead.org \
    --cc=tony.luck@intel.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;
as well as URLs for NNTP newsgroup(s).