On 06/20/2014 11:58 AM, Borislav Petkov wrote:
On Fri, Jun 20, 2014 at 11:41:27AM -0400, Boris Ostrovsky wrote:
Only in the sense that on Xen misc_register() often fails. But any
failure on baremetal will result in the same behavior.
Ok, thanks for explaining the details.
Right. And I think we shouldn't because we leave undeleted timers.
I wonder if we could simply move the oneliner:
__register_hotcpu_notifier(&mce_cpu_notifier);
to mcheck_init()? We don't need any locking there because we're pre-SMP
then and from looking at notifier_chain_register(), it seems there's
nothing special that needs initializing for the call to be too early -
we're simply adding the callback to a list...
Hmm, because if that would work, the fix is almost trivial. :)
That's cleaner than what I had in mcheck_cpu_init() (checking for
boot_cpu_data).
But I think you still need to do the dance in the notifier to make sure
you are not trying to add/remove device if mcheck_init_device() had
failed earlier.
-boris
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
