Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:7 as permitted sender) client-ip=2620:137:e000::3:7;
Content-Type: text/plain;
        charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.700.6\))
Subject: Re: [PATCH 2/3] userfaultfd: UFFDIO_REMAP uABI
From:   Nadav Amit <nadav.amit@gmail.com>
In-Reply-To: <CAJuCfpGWkzDUL4+9evD-Kx5uGoc+=g808CXtc1hrSUdCRMtRgA@mail.gmail.com>
Date:   Thu, 14 Sep 2023 21:03:45 -0700
Cc:     Andrew Morton <akpm@linux-foundation.org>, viro@zeniv.linux.org.uk,
        brauner@kernel.org, shuah@kernel.org,
        Andrea Arcangeli <aarcange@redhat.com>, lokeshgidra@google.com,
        Peter Xu <peterx@redhat.com>,
        David Hildenbrand <david@redhat.com>,
        Hugh Dickins <hughd@google.com>, mhocko@suse.com,
        Axel Rasmussen <axelrasmussen@google.com>,
        Mike Rapoport <rppt@kernel.org>,
        Matthew Wilcox <willy@infradead.org>, Liam.Howlett@oracle.com,
        Jann Horn <jannh@google.com>, zhangpeng362@huawei.com,
        bgeffon@google.com, kaleshsingh@google.com, ngeoffray@google.com,
        jdduke@google.com, linux-mm <linux-mm@kvack.org>,
        linux-fsdevel@vger.kernel.org,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        linux-kselftest@vger.kernel.org, kernel-team@android.com
Content-Transfer-Encoding: quoted-printable
Message-Id: <C04B3D0F-A757-49A5-9CF4-3387EED41562@gmail.com>
References: <20230914152620.2743033-1-surenb@google.com>
 <20230914152620.2743033-3-surenb@google.com>
 <4F9BBE45-22D0-4F8D-BA56-CA3459998DC4@gmail.com>
 <CAJuCfpGWkzDUL4+9evD-Kx5uGoc+=g808CXtc1hrSUdCRMtRgA@mail.gmail.com>
To:     Suren Baghdasaryan <surenb@google.com>
Precedence: bulk


> On Sep 14, 2023, at 8:28 PM, Suren Baghdasaryan <surenb@google.com> =
wrote:
>=20
> On Thu, Sep 14, 2023 at 2:57=E2=80=AFPM Nadav Amit =
<nadav.amit@gmail.com> wrote:
>>=20
>>=20
>>> On Sep 14, 2023, at 8:26 AM, Suren Baghdasaryan <surenb@google.com> =
wrote:
>>>=20
>>> +     if (!pte_same(ptep_clear_flush(src_vma, src_addr, src_pte),
>>> +             orig_src_pte))
>>> +             BUG_ON(1);
>>=20
>> Just a minor detail regarding these few lines:
>>=20
>> Besides the less-than-ideal use of BUG_ON() here, I think that this =
code
>> assumes that the PTE cannot change at this point. However, as the PTE =
was
>> still mapped at this point, I think the access and dirty bits can be =
set.
>=20
> At this point we are holding PTLs for both PTEs (see
> double_pt_lock()).  Can a PTE be modified from under us in this
> situation?

PTEs has several parts: access-control bits (e.g., writable), physical
frame number, software-only bits and log-bits. The log-bits, which are
=E2=80=9Caccess=E2=80=9D and =E2=80=9Cdirty=E2=80=9D on x86, track =
whether the PTE has ever been used
for translation or write correspondingly.

Without getting into all the subtleties (e.g., =E2=80=9Caccess" can be =
set
speculatively even if no actual access take place), as long as the PTE
is present, it might be used for access (and write if it is writable)
by other cores. The page-table locks are irrelevant here, because the
PTE is not updated by software, but it is updated by the CPU itself
during the page-walk/write.