Messages in this thread | | | Date | Tue, 21 Jul 2015 12:03:30 +0200 | From | Borislav Petkov <> | Subject | Re: [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. --
| |