Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Content-Type: text/plain;
        charset=utf-8
Mime-Version: 1.0 (1.0)
Subject: Re: [GIT PULL] x86/mm changes for v4.21
From:   Andy Lutomirski <luto@amacapital.net>
In-Reply-To: <20190207184606.GB17049@agluck-desk>
Date:   Thu, 7 Feb 2019 12:24:18 -0800
Cc:     Peter Zijlstra <peterz@infradead.org>,
        Linus Torvalds <torvalds@linux-foundation.org>,
        Dan Williams <dan.j.williams@intel.com>,
        Ingo Molnar <mingo@kernel.org>,
        Linux List Kernel Mailing <linux-kernel@vger.kernel.org>,
        Dave Hansen <dave.hansen@linux.intel.com>,
        Andy Lutomirski <luto@kernel.org>,
        Borislav Petkov <bp@alien8.de>,
        Thomas Gleixner <tglx@linutronix.de>,
        Rik van Riel <riel@surriel.com>
Content-Transfer-Encoding: quoted-printable
Message-Id: <22E08A6D-5180-42F1-B94B-6B6DB832F953@amacapital.net>
References: <20181224231106.GA27438@gmail.com> <20190207001737.GA32096@agluck-desk> <20190207101846.GB32511@hirez.programming.kicks-ass.net> <CAHk-=whSRGDk9437PvMFEvDvc5hr73fXj+CvNHZu=vNE=GFDFg@mail.gmail.com> <20190207140131.GB32477@hirez.programming.kicks-ass.net> <20190207173600.GA15682@agluck-desk> <20190207175720.GE32511@hirez.programming.kicks-ass.net> <8D8DF81C-3331-4105-8594-9600281010EF@amacapital.net> <20190207184606.GB17049@agluck-desk>
To:     "Luck, Tony" <tony.luck@intel.com>
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk


> On Feb 7, 2019, at 10:46 AM, Luck, Tony <tony.luck@intel.com> wrote:
>=20
>> On Thu, Feb 07, 2019 at 10:07:28AM -0800, Andy Lutomirski wrote:
>> Joining this thread late...
>>=20
>> 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=E2=80=99s some chicken bit we can set to improve the situati=
on
>> while we=E2=80=99re in the MCE handler.
>=20
>> Also, since I don=E2=80=99t really want
>> to dig into the code to answer this, how exactly do we do a broadcast TLB=

>> flush from MCE context?  We=E2=80=99re super-duper-atomic, and locks migh=
t be
>> held on various CPUs.  Shouldn=E2=80=99t we be telling the cpa code to sk=
ip
>> 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.
>=20
> MCE code doesn't do this while still in MCE context. You helped
> restructure this code so the recovery bits happen after we call
>=20
>    ist_begin_non_atomic(regs);
>=20
> on just the CPU that hit the error (in the broadcast case we've
> let the other out of MCE jail by this point).
>=20
> 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?

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