Re: [RFC PATCH v2 11/12] x86/mm/tlb: Use async and inline messages for flushing

[Dave Hansen <dave.hansen@intel.com>]

On 5/31/19 1:37 PM, Andy Lutomirski wrote:
>> Modulo bugs^Werrata...  No.  What actually happens is that a
>> try-to-set-dirty-bit page table walk acts just like a TLB miss.  The old
>> contents of the TLB are discarded and only the in-memory contents matter
>> for forward progress.  If Present=0 when the PTE is reached, you'll get
>> a normal Present=0 page fault.
> Wait, does that mean that you can do a lock cmpxchg or similar to
> clear the dirty and writable bits together and, if the dirty bit was
> clear, skip the TLB flush?

Yeah, in the case that you're going from R/W->R/O, you can be assured
that no writable TLB entries were established if D=0.

Is it totally safe against other things?  Hell if I know. :)

I'd want to go look very closely at software things like GUP-for-write
before we went and actually did this.  But I can't think of any hardware
reasons off the top of my head why it wouldn't work.

A quick perusal of the SDM didn't have any slam dunks do support doing
this.  It's a bit cagey about exactly what can be cached and when.  The
supporting reasoning might have escaped my quick scan, though.

> If so, nifty!  Modulo errata, of course. And I seem to remember some
> exceptions relating to CET shadow stack involving the dirty bit being
> set on not-present pages.

Yeah: "no processor that supports CET will ever set the dirty flag in a
paging-structure entry in which the R/W flag is 0"

> https://software.intel.com/sites/default/files/managed/4d/2a/control-flow-enforcement-technology-preview.pdf

Which probably means that the things we were saying above are
technically only architectural on CET-enabled processors.  I think the
behavior is actually much more widespread than that, though.