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. > > > > Cc: <sta...@vger.kernel.org> > > 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. -- Catalin
