RE: [RFC PATCH 2/3] x86, MCE: Avoid potential deadlock in MCE context

["Luck, Tony" <tony.luck@intel.com>]

> This patch is overengineered even though we already have both process
> context work and irq work facilities in place.
>
> We also already have mce_ring where we add MCE signatures in #MC
> context. Well, only for AO errors with usable addresses for now, at
> least.

We've evolved a bunch of mechanisms:

1) mce_ring: to pass pfn for AO errors from MCE context to a work thread
2) mce_info: to pass pfn for AR errors from MCE context to same process running in process context
3) mce_log: to pass entire "mce" structures from any context (MCE, CMCI, or init-time) to /dev/mcelog

something simpler might be nice - but a generic thing that is overkill for each of the
specialized uses might not necessarily be an improvement.

E.g. #3 above has a fixed capacity (MCE_LOG_LEN) and just drops any extras if it should fill
up (deliberately, because we almost always prefer to see the first bunch of errors rather
than the newest).

> I think it would be a *lot* simpler if you modify the logic to put all
> errors into the ring and remove the call chain call from mce_log().

I was actually wondering about going in the other direction. Make the
/dev/mcelog code register a notifier on x86_mce_decoder_chain (and
perhaps move all the /dev/mcelog functions out of mce.c into an actual
driver file).  Then use Chen Gong's NMI safe code to just unconditionally
make safe copies of anything that gets passed to mce_log() and run all
the notifiers from his do_mce_irqwork().

-Tony