[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20140627160841.GH23153@pd.tnic>
Date: Fri, 27 Jun 2014 18:08:41 +0200
From: Borislav Petkov <bp@...en8.de>
To: Boris Ostrovsky <boris.ostrovsky@...cle.com>
Cc: Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>,
x86-ml <x86@...nel.org>, Tony Luck <tony.luck@...el.com>,
lkml <linux-kernel@...r.kernel.org>
Subject: Re: [GIT PULL] 2 RAS fixes for 3.17, refreshed
On Fri, Jun 27, 2014 at 11:12:59AM -0400, Boris Ostrovsky wrote:
> Yes, it fails because xen_late_init_mcelog() registers /dev/mcelog and (I
> think) it happens before mcheck_init_device().
Yes, mcheck_init_device is device_initcall_sync() while
xen_late_init_mcelog() is device_initcall().
> In other words, misc_register() expected to fail in mcheck/mce.c on
> (privileged?) PV guests (provided right CONFIG_XEN_* is set).
So
cef12ee52b05 ("xen/mce: Add mcelog support for Xen platform")
made it this way so that xen's init routine runs first.
So it is not the case that misc_register() fails often on xen but it is
*supposed* to fail by design, when running in dom0. And *then* you need
the notifier *not* unregistered on the error path so that the timers do
get deleted properly.
Ok, I see it now. Frankly, I'm not really sure I want to rush this in
now because it might break something else, Who TF knows what.
Right now my gut feeling tells me we should still queue it for 3.17 and
have it run for a while in linux-next. We can backport it to stable
later after some testing...
Hmmm.
--
Regards/Gruss,
Boris.
Sent from a fat crate under my desk. Formatting is fine.
--
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists