• Catalin Marinas's avatar
    arm64: Implement ptep_set_access_flags() for hardware AF/DBM · 66dbd6e6
    Catalin Marinas authored
    When hardware updates of the access and dirty states are enabled, the
    default ptep_set_access_flags() implementation based on calling
    set_pte_at() directly is potentially racy. This triggers the "racy dirty
    state clearing" warning in set_pte_at() because an existing writable PTE
    is overridden with a clean entry.
    
    There are two main scenarios for this situation:
    
    1. The CPU getting an access fault does not support hardware updates of
       the access/dirty flags. However, a different agent in the system
       (e.g. SMMU) can do this, therefore overriding a writable entry with a
       clean one could potentially lose the automatically updated dirty
       status
    
    2. A more complex situation is possible when all CPUs support hardware
       AF/DBM:
    
       a) Initial state: shareable + writable vma and pte_none(pte)
       b) Read fault taken by two threads of the same process on different
          CPUs
       c) CPU0 takes the mmap_sem and proceeds to handling the fault. It
          eventually reaches do_set_pte() which sets a writable + clean pte.
          CPU0 releases the mmap_sem
       d) CPU1 acquires the mmap_sem and proceeds to handle_pte_fault(). The
          pte entry it reads is present, writable and clean and it continues
          to pte_mkyoung()
       e) CPU1 calls ptep_set_access_flags()
    
       If between (d) and (e) the hardware (another CPU) updates the dirty
       state (clears PTE_RDONLY), CPU1 will override the PTR_RDONLY bit
       marking the entry clean again.
    
    This patch implements an arm64-specific ptep_set_access_flags() function
    to perform an atomic update of the PTE flags.
    
    Fixes: 2f4b829c ("arm64: Add support for hardware updates of the access and dirty pte bits")
    Signed-off-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
    Reported-by: default avatarMing Lei <tom.leiming@gmail.com>
    Tested-by: default avatarJulien Grall <julien.grall@arm.com>
    Cc: Will Deacon <will.deacon@arm.com>
    Cc: <stable@vger.kernel.org> # 4.3+
    [will: reworded comment]
    Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
    66dbd6e6
fault.c 18.6 KB