Re: [GIT PULL] x86/mm changes for v4.21

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

On Thu, Feb 07, 2019 at 10:07:28AM -0800, Andy Lutomirski wrote:
> Joining this thread late...
> 
> This is all IMO rather crazy.  How about we fiddle with CR0 to turn off
> the cache, then fiddle with page tables, then turn caching on?  Or, heck,
> see if there’s some chicken bit we can set to improve the situation
> while we’re in the MCE handler.

> Also, since I don’t really want
> to dig into the code to answer this, how exactly do we do a broadcast TLB
> flush from MCE context?  We’re super-duper-atomic, and locks might be
> held on various CPUs.  Shouldn’t we be telling the cpa code to skip
> the flush and then just have the MCE code do a full flush manually?
> The MCE code has already taken over all CPUs on non-LMCE systems.

MCE code doesn't do this while still in MCE context. You helped
restructure this code so the recovery bits happen after we call

	ist_begin_non_atomic(regs);

on just the CPU that hit the error (in the broadcast case we've
let the other out of MCE jail by this point).

So there is a small window where we know the broken page is still
mapped WB in the kernel 1:1 map. But we just live dangerously for
a few more microseconds until we can fix the map.

> Or, better yet, get Intel to fix the hardware. A failed speculative
> access while already in MCE context should just be ignored.

Good idea.

-Tony