From: Corey Minyard <minyard@acm.org>
To: Borislav Petkov <bp@alien8.de>
Cc: "Luck, Tony" <tony.luck@intel.com>,
Steven Rostedt <rostedt@goodmis.org>,
"linux-rt-users@vger.kernel.org" <linux-rt-users@vger.kernel.org>,
Corey Minyard <cminyard@mvista.com>
Subject: Re: [PATCH][RT] x86: Fix an RT MCE crash
Date: Thu, 30 Jun 2016 12:54:14 -0500 [thread overview]
Message-ID: <57755CC6.60506@acm.org> (raw)
In-Reply-To: <20160630172611.GC3932@pd.tnic>
On 06/30/2016 12:26 PM, Borislav Petkov wrote:
> On Thu, Jun 30, 2016 at 12:18:01PM -0500, Corey Minyard wrote:
>> This is on 3.10-rt with PREEMPT_RT enabled. It appears that from 3.18-rt
>> and later it has code like the change I have proposed, so it does not crash.
>>
>> I could add a something to see if the interrupt is coming in early to
>> 4.6-rt,
>> is that what you are looking for?
> Actually, I'd like to know first whether the unpatched upstream kernel -
> not -rt - is crashing.
It won't crash. If you disable PREEMPT_RT on the 3.10-rt kernel it won't
crash (which I have tested). With PREEMPT_RT, the kernel creates a
separate thread that is woken on mce notifications. The trouble is
that the interrupts are initialized before the thread is created.
> And then 4.6-rt.
>
> Because from looking at your splat, you're getting a thresholding
> interrupt the moment you enable the local APIC and from staring at the
> MCE code upstream, I think we should be prepared for that scenario.
>
> AFAICT, both -rt and upstream should handle that case just fine and I'm
> guessing upstream was fixed at some point and -rt grew another fix which
> is probably not needed and it should take the upstream one instead...
This is not a bug in mainline. This is only an RT bug, and only
with PREEMPT_RT enabled.
I can try these things if you really want, but it doesn't seem like
a useful activity to me.
It looks like in 3.18-rt someone noticed this issue and fixed it,
but the fix wasn't backported to earlier kernels. I'm really just
trying to get that fix backported.
-corey
next prev parent reply other threads:[~2016-06-30 17:54 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-06-30 13:24 [PATCH][RT] x86: Fix an RT MCE crash minyard
2016-06-30 13:43 ` Steven Rostedt
2016-06-30 14:49 ` Corey Minyard
2016-06-30 15:51 ` Steven Rostedt
2016-06-30 15:58 ` Corey Minyard
2016-06-30 16:01 ` Borislav Petkov
2016-06-30 16:17 ` Luck, Tony
2016-06-30 16:40 ` Corey Minyard
2016-06-30 17:01 ` Borislav Petkov
2016-06-30 17:18 ` Corey Minyard
2016-06-30 17:26 ` Borislav Petkov
2016-06-30 17:54 ` Corey Minyard [this message]
2016-06-30 18:22 ` Borislav Petkov
2016-06-30 19:44 ` Corey Minyard
2016-06-30 20:34 ` Borislav Petkov
2016-06-30 22:47 ` Corey Minyard
2016-07-01 7:20 ` Borislav Petkov
2016-07-06 0:59 ` Corey Minyard
2016-07-06 8:37 ` Borislav Petkov
2016-07-06 12:03 ` Corey Minyard
2016-07-06 13:32 ` Steven Rostedt
2016-07-06 13:43 ` Sebastian Andrzej Siewior
2016-07-11 17:32 ` Steven Rostedt
2016-07-01 9:20 ` Daniel Wagner
2016-06-30 16:04 ` Corey Minyard
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=57755CC6.60506@acm.org \
--to=minyard@acm.org \
--cc=bp@alien8.de \
--cc=cminyard@mvista.com \
--cc=linux-rt-users@vger.kernel.org \
--cc=rostedt@goodmis.org \
--cc=tony.luck@intel.com \
/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).