lkml.org 
[lkml]   [2019]   [Feb]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [GIT PULL] x86/mm changes for v4.21
From
Date


> 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

\
 
 \ /
  Last update: 2019-02-07 21:24    [W:0.090 / U:0.888 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site