Re: [PATCH 2/3] userfaultfd: UFFDIO_REMAP uABI

[Nadav Amit <nadav.amit@gmail.com>]

> On Sep 14, 2023, at 8:28 PM, Suren Baghdasaryan <surenb@google.com> wrote:
> 
> On Thu, Sep 14, 2023 at 2:57 PM Nadav Amit <nadav.amit@gmail.com> wrote:
>> 
>> 
>>> On Sep 14, 2023, at 8:26 AM, Suren Baghdasaryan <surenb@google.com> wrote:
>>> 
>>> +     if (!pte_same(ptep_clear_flush(src_vma, src_addr, src_pte),
>>> +             orig_src_pte))
>>> +             BUG_ON(1);
>> 
>> Just a minor detail regarding these few lines:
>> 
>> 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.
> 
> 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
“access” and “dirty” on x86, track whether the PTE has ever been used
for translation or write correspondingly.

Without getting into all the subtleties (e.g., “access" 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.