x86: Merge tag 'ras_urgent' into x86/urgent
authorH. Peter Anvin <hpa@linux.intel.com>
Thu, 24 Jul 2014 23:32:31 +0000 (16:32 -0700)
committerH. Peter Anvin <hpa@linux.intel.com>
Thu, 24 Jul 2014 23:32:31 +0000 (16:32 -0700)
commitbf72f5dee0656cfa9dc40bcb533f08d1d144e6ea
treec3b382b9b36319a98e1eabbdd842d97fb745c1c7
parent2a2261553dd1472ca574acadbd93e12f44c4e6d5
parent51cbe7e7c400def749950ab6b2c120624dbe21a7
x86: Merge tag 'ras_urgent' into x86/urgent

Promote one fix for 3.16

This fix was necessary after

9c15a24b038f ("x86/mce: Improve mcheck_init_device() error handling")

went in. What this patch did was, among others, check the return value
of misc_register and exit early if it encountered an error. Original
code sloppily didn't do that.

However,

        cef12ee52b05 ("xen/mce: Add mcelog support for Xen platform")

made it so that xen's init routine xen_late_init_mcelog runs first. This
was needed for the xen mcelog device which is supposed to be independent
from the baremetal one.

Initially it was reported that misc_register() fails often on xen and
that's why it needed fixing. However, it is *supposed* to fail by
design, when running in dom0 so that the xen mcelog device file gets
registered first.

And *then* you need the notifier *not* unregistered on the error path so
that the timer does get deleted properly in the CPU hotplug notifier.

Btw, this fix is needed also on baremetal in the unlikely event that
misc_register(&mce_chrdev_device) fails there too.

I was unsure whether to rush it in now and decided to delay it to 3.17.
However, xen people wanted it promoted as it breaks xen when doing cpu
hotplug there. So, after a bit of simmering in tip/master for initial
smoke testing, let's move it to 3.16. It fixes a semi-regression which
got introduced in 3.16 so no need for stable tagging.

tip/x86/ras contains that exact same commit but we can't remove it
there as it is not the last one. It won't cause any merge issues, as I
confirmed locally but I should state here the special situation of this
one fix explicitly anyway.

Thanks.

Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>