On Fri, Nov 20, 2020 at 09:09:03AM -0800, Minchan Kim wrote:
On Fri, Nov 20, 2020 at 02:35:53PM +0000, Will Deacon wrote:
With hardware dirty bit management, calling pte_wrprotect() on a writable, dirty PTE will lose the dirty state and return a read-only, clean entry.
Move the logic from ptep_set_wrprotect() into pte_wrprotect() to ensure that the dirty bit is preserved for writable entries, as this is required for soft-dirty bit management if we enable it in the future.
It this stable material if it would be a problem once ARM64 supports softdirty in future?
I don't think so. Arm64 did not have a hardware dirty mechanism from the start, it was added later but in a way as to coexist with other CPUs or peripherals that don't support it. So instead of setting a PTE_DIRTY bit as one would expect, the CPU clears the PTE_RDONLY on write access to a writable PTE (the PTE_DBM/PTE_WRITE bit set). So our pte_wrprotect() needs to set PTE_RDONLY and clear PTE_DBM (PTE_WRITE) but !PTE_RDONLY is our only information of a pte having been dirtied, so we have to transfer it to a software PTE_DIRTY bit. This is different from a soft-dirty pte bit if we add it in the future.