Re: [PATCH 1/2] x86: mce: kdump: use under_crashdumping to turn off MCE in all CPUs together

[Naoya Horiguchi]

On Tue, Feb 24, 2015 at 10:56:16AM +0100, Borislav Petkov wrote:
> On Tue, Feb 24, 2015 at 08:15:35AM +0000, Naoya Horiguchi wrote:
> > Let me update my explanation about the problem. I wrote the description about
> > race window of nmi shoot down threads. That's not wrong, but that's only the
> > part of the problem. The more suitable description is that all "shot down"
> > CPUs keep MCE enabled (disable_local_APIC() doesn't stop it) after entering
> > infinite loop of cpu_relax(), so any MCE event causes kernel panic due to
> > synchronization timeout whenever after the 2nd kernel launches on the crashing
> > CPU (where the CPU don't run do_machine_check(), but the other CPUs do).
> 
> Ok, now we're getting closer.
> 
> So, I'm thinking you want to disable MCA on all cores going offline
> as part of the work done in crash_nmi_callback(). And off the top
> of my head, it should be something what mcheck_cpu_init() and
> __mcheck_cpu_init_generic() in particular does but in reverse.
> 
> I'd even venture a guess and say that clearing CR4.MCE should be enough
> but I *think* that doesn't prevent errors from being logged. Just to be
> extra sure, you should clear MCG_CTL bits too. It all depends on what
> exactly you want to do.

Comparing with setting tolerant to 3, clearing CR4.MCE and MCG_CTL has one
benefit that we can also disable reporting to userspace.
do_machine_check() calls mce_report_event() which makes the mcelog process
read the log from /dev/mcelog and write it to storage even when tolerant == 3,
but we can't expect that works correctly under kdump context.
So keeping log data on /dev/mcelog buffer and letting them included in the
crashdump looks better to me.

Thanks,
Naoya Horiguchi--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/