[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20170412221639.5klmqk4mjbvy6btx@pd.tnic>
Date: Thu, 13 Apr 2017 00:16:39 +0200
From: Borislav Petkov <bp@...e.de>
To: "Luck, Tony" <tony.luck@...el.com>
Cc: Thomas Gleixner <tglx@...utronix.de>,
Dan Williams <dan.j.williams@...el.com>,
"Verma, Vishal L" <vishal.l.verma@...el.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-nvdimm@...ts.01.org" <linux-nvdimm@...1.01.org>,
"ross.zwisler@...ux.intel.com" <ross.zwisler@...ux.intel.com>,
"x86@...nel.org" <x86@...nel.org>
Subject: Re: [RFC PATCH] x86, mce: change the mce notifier to 'blocking' from
'atomic'
On Wed, Apr 12, 2017 at 11:47:49PM +0200, Borislav Petkov wrote:
> so we need to think about something better to handle events down the
> whole chain. Maybe route events from the atomic path to the blocking
> path where the sleeping notifier callbacks can sleep as much as they
> want to...
... and it is midnight here so I could be talking crap but we probably
should really split the reporting "chain" into two:
1. atomic context which doesn't do any notifier wankery. We simply call
non-sleeping functions one after the other. And those should be fast and
not taking any locks.
For example, I'm thinking you want to decode the error and that's it. So
we can replace the notifier call in print_mce() with our atomic context
function.
Then:
2. move the notifier completely in process context, convert it to a
blocking one and connect there all the noodling stuff like EDAC, NFIT,
mcelog, EXTLOG, ... I.e., all the logging machinery.
Problem solved.
And here's where you come in and say, "Boris, you're talking crap.." :-)
Lemme sleep on it.
--
Regards/Gruss,
Boris.
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)
--
Powered by blists - more mailing lists