Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Content-Type: text/plain;
        charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\))
Subject: Re: [PATCH v2 2/5] mm: avoid unnecessary flush on change_huge_pmd()
From:   Nadav Amit <nadav.amit@gmail.com>
In-Reply-To: <435f41f2-ffd4-0278-9f26-fbe2c2c7545c@intel.com>
Date:   Tue, 26 Oct 2021 12:06:40 -0700
Cc:     Linux-MM <linux-mm@kvack.org>, LKML <linux-kernel@vger.kernel.org>,
        Andrea Arcangeli <aarcange@redhat.com>,
        Andrew Cooper <andrew.cooper3@citrix.com>,
        Andrew Morton <akpm@linux-foundation.org>,
        Andy Lutomirski <luto@kernel.org>,
        Dave Hansen <dave.hansen@linux.intel.com>,
        Peter Xu <peterx@redhat.com>,
        Peter Zijlstra <peterz@infradead.org>,
        Thomas Gleixner <tglx@linutronix.de>,
        Will Deacon <will@kernel.org>, Yu Zhao <yuzhao@google.com>,
        Nick Piggin <npiggin@gmail.com>,
        "x86@kernel.org" <x86@kernel.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <8BC74789-FF33-403F-B5D7-19034CAC7EE6@gmail.com>
References: <20211021122112.592634-1-namit@vmware.com>
 <20211021122112.592634-3-namit@vmware.com>
 <c415820a-aebb-265c-7f47-e048ee429102@intel.com>
 <E38AEB97-DE1B-4C91-A959-132EC24812AE@vmware.com>
 <29E7E8A4-C400-40A5-ACEC-F15C976DDEE0@gmail.com>
 <435f41f2-ffd4-0278-9f26-fbe2c2c7545c@intel.com>
To:     Dave Hansen <dave.hansen@intel.com>
Precedence: bulk


> On Oct 26, 2021, at 11:44 AM, Dave Hansen <dave.hansen@intel.com> =
wrote:
>=20
> On 10/26/21 10:44 AM, Nadav Amit wrote:
>>> "If software on one logical processor writes to a page while =
software on
>>> another logical processor concurrently clears the R/W flag in the
>>> paging-structure entry that maps the page, execution on some =
processors may
>>> result in the entry=E2=80=99s dirty flag being set (due to the write =
on the first
>>> logical processor) and the entry=E2=80=99s R/W flag being clear (due =
to the update
>>> to the entry on the second logical processor). This will never occur =
on a
>>> processor that supports control-flow enforcement technology (CET)=E2=80=
=9D
>>>=20
>>> So I guess that this optimization can only be enabled when CET is =
enabled.
>>>=20
>>> :(
>> I still wonder whether the SDM comment applies to present bit vs =
dirty
>> bit atomicity as well.
>=20
> I think it's implicit.  =46rom "4.8 ACCESSED AND DIRTY FLAGS":
>=20
> 	"Whenever there is a write to a linear address, the processor
> 	 sets the dirty flag (if it is not already set) in the paging-
> 	 structure entry"
>=20
> There can't be a "write to a linear address" without a Present=3D1 =
PTE.
> If it were a Dirty=3D1,Present=3D1 PTE, there's no race because there =
might
> not be a write to the PTE at all.
>=20
> There's also this from the "4.10.4.3 Optional Invalidation" section:
>=20
> 	"no TLB entry or paging-structure cache entry is created with
> 	 information from a paging-structure entry in which the P flag
> 	 is 0."
>=20
> That means that we don't have to worry about the TLB doing something
> bonkers like caching a Dirty=3D1 bit from a Present=3D0 PTE.
>=20
> Is that what you were worried about?

Thanks Dave, but no - that is not my concern.

To make it very clear - consider the following scenario, in which
a volatile pointer p is mapped using a certain PTE, which is RW
(i.e., *p is writable):

  CPU0				CPU1
  ----				----
  x =3D *p
  [ PTE cached in TLB;=20
    PTE is not dirty ]
				clear_pte(PTE)
  *p =3D x
  [ needs to set dirty ]

Note that there is no TLB flush in this scenario. The question
is whether the write access to *p would succeed, setting the
dirty bit on the clear, non-present entry.

I was under the impression that the hardware AD-assist would
recheck the PTE atomically as it sets the dirty bit. But, as I
said, I am not sure anymore whether this is defined architecturally
(or at least would work in practice on all CPUs modulo the=20
Knights Landing thingy).