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: <CAHk-=wiZ3t_YbtRz1tLTEvF0JS1DH07DdDR3FP-FHcZW8wfSAw@mail.gmail.com>
Date:   Thu, 7 Feb 2019 15:05:54 -0800
Cc:     "Luck, Tony" <tony.luck@intel.com>,
        Peter Zijlstra <peterz@infradead.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: <42A9C88A-DFA3-4936-BA4E-F853E5871ACF@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> <22E08A6D-5180-42F1-B94B-6B6DB832F953@amacapital.net> <CAHk-=wiZ3t_YbtRz1tLTEvF0JS1DH07DdDR3FP-FHcZW8wfSAw@mail.gmail.com>
To:     Linus Torvalds <torvalds@linux-foundation.org>
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk


> On Feb 7, 2019, at 2:53 PM, Linus Torvalds <torvalds@linux-foundation.org>=
 wrote:
>=20
>> On Thu, Feb 7, 2019 at 1:24 PM Andy Lutomirski <luto@amacapital.net> wrot=
e:
>>=20
>> How bad would it be to set CR0.CD while fiddling with the page tables rat=
her than masking the address?
>=20
> I would suggest against it. When you disable caching, things don't
> just go "slightly slower". Everything comes to a screeching halt, with
> instruction fetch etc becoming a serious problem.
>=20
> So disabling caching for a few instructions in a very simple asm
> snippet might be reasonable (particularly since you could pre-fetch
> the cache and just rely on CR0.CD not fetching *new* lines). But doing
> it in C code that might have things like tracing enabled etc? I'd be
> very very leery.
>=20
>=20

In principle, it=E2=80=99s just the code that walks the page tables and chan=
ges the mode.  But we could get a perf NMI and take who knows how long to pr=
ocess it if caching is off.=