On Fri, Sep 15, 2023 at 4:04 AM Nadav Amit nadav.amit@gmail.com wrote:
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.
Ah, I see. I believe Jann also pointed this out in one of his comments and I didn't realize that. Thanks for the note! I'll see how I can rework this.
-- To unsubscribe from this group and stop receiving emails from it, send an email to kernel-team+unsubscribe@android.com.