Re: [PATCH 4/6] mm: proc: Invalidate TLB after clearing soft-dirty page state
From: Peter Zijlstra <peterz@infradead.org>
Date: 2020-11-20 15:00:33
Also in:
linux-mm, lkml
On Fri, Nov 20, 2020 at 02:35:55PM +0000, Will Deacon wrote:
Since commit 0758cd830494 ("asm-generic/tlb: avoid potential double flush"),
TLB invalidation is elided in tlb_finish_mmu() if no entries were batched
via the tlb_remove_*() functions. Consequently, the page-table modifications
performed by clear_refs_write() in response to a write to
/proc/<pid>/clear_refs do not perform TLB invalidation. Although this is
fine when simply aging the ptes, in the case of clearing the "soft-dirty"
state we can end up with entries where pte_write() is false, yet a
writable mapping remains in the TLB.
Fix this by calling tlb_remove_tlb_entry() for each entry being
write-protected when cleating soft-dirty.quoted hunk ↗ jump to hunk
@@ -1053,6 +1054,7 @@ static inline void clear_soft_dirty(struct vm_area_struct *vma, ptent = pte_wrprotect(old_pte); ptent = pte_clear_soft_dirty(ptent); ptep_modify_prot_commit(vma, addr, pte, old_pte, ptent); + tlb_remove_tlb_entry(tlb, pte, addr); } else if (is_swap_pte(ptent)) { ptent = pte_swp_clear_soft_dirty(ptent); set_pte_at(vma->vm_mm, addr, pte, ptent);
Oh! Yesterday when you had me look at this code; I figured the sane thing to do was to make it look more like mprotect(). Why did you chose to make it work with mmu_gather instead? I'll grant you that it's probably the smaller patch, but I still think it's weird to use mmu_gather here. Also, is tlb_remote_tlb_entry() actually correct? If you look at __tlb_remove_tlb_entry() you'll find that Power-Hash-32 will clear the entry, which might not be what we want here, we want to update the entrty. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel