Re: [PATCH 1/7] x86/mce: Provide a lockless memory pool to save error records

[Borislav Petkov <bp@suse.de>]

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.
--