lkml.org 
[lkml]   [2015]   [Jul]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 1/7] x86/mce: Provide a lockless memory pool to save error records
On Tue, Jul 21, 2015 at 10:29:49AM +0200, Ingo Molnar wrote:
> So this change appears to be completely unrelated to the stated purpose of this
> patch?

I'll carve it out into a separate patch.

> Missing comma.

Good point.

> So I think the standard pattern for allocation failures with integer types is to
> return -ENOMEM, not bool. This really matters, because:

...

> here gen_pool_add() has an inverted logic, and they looks confusing.

Lemme fix that.

> Furthermore, why do we spell it 'mce_genpool' if the generic facility is spelling
> it gen_pool?

mce_gen_pool() it is.

> So how are we going to report uncorrectable errors that forcibly
> crash/panic the system if we cannot use printk? How will the admin
> learn what was amiss?

There's no change to that policy - we still panic for MCEs of
MCE_PANIC_SEVERITY and higher. And mce_panic() does use printk() to dump
that critical information.

The gen_pool stuff is for MCEs for which the hw still raises an #MC
exception but the severity code determines that we don't need to panic
but do recovery action.

However, we don't want to call printk() from the #MC exception handler
since it is NMI-like atomic context and printk is not NMI-safe (yet).
Those printks are issued later, in process context when we're done with
the exception handler and recovery action.

--
Regards/Gruss,
Boris.

ECO tip #101: Trim your mails when you reply.
--


\
 
 \ /
  Last update: 2015-07-21 12:21    [W:0.075 / U:0.064 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site