Messages in this thread | | | Subject | Re: [GIT PULL] x86/mm changes for v4.21 | From | Andy Lutomirski <> | Date | Thu, 7 Feb 2019 12:24:18 -0800 |
| |
> On Feb 7, 2019, at 10:46 AM, Luck, Tony <tony.luck@intel.com> wrote: > >> 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.
Hmm.
How bad would it be to set CR0.CD while fiddling with the page tables rather than masking the address?
> >> 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
| |