From: Catalin Marinas <catalin.marinas@arm.com> To: Will Deacon <will@kernel.org> Cc: linux-kernel@vger.kernel.org, kernel-team@android.com, Yu Zhao <yuzhao@google.com>, Minchan Kim <minchan@kernel.org>, Peter Zijlstra <peterz@infradead.org>, Linus Torvalds <torvalds@linux-foundation.org>, Anshuman Khandual <anshuman.khandual@arm.com>, linux-mm@kvack.org, linux-arm-kernel@lists.infradead.org, stable@vger.kernel.org Subject: Re: [PATCH 2/6] arm64: pgtable: Ensure dirty bit is preserved across pte_wrprotect() Date: Mon, 23 Nov 2020 14:22:37 +0000 [thread overview] Message-ID: <20201123142237.GF17833@gaia> (raw) In-Reply-To: <20201120143557.6715-3-will@kernel.org> 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. My assumption at the time was that the caller of pte_wrprotect() already moved the 'dirty' information to the underlying page. Most pte_wrprotect() calls also do a pte_mkclean(). However, it doesn't seem to always be the case (soft-dirty but we don't support it yet). I was worried that we may inadvertently set the dirty bit when doing a pte_wrprotect() on a freshly created pte (not read from memory, for example __split_huge_pmd_locked()) but I think all our __P* and __S* attributes start with a PTE_RDONLY, therefore the pte_hw_dirty() returns false. A test for mm/debug_vm_pgtable.c, something like: for (i = 0, i < ARRAY_SIZE(protection_map); i++) { pte = pfn_pte(pfn, protection_map(i)); WARN_ON(pte_dirty(pte_wrprotect(pte)); } (I'll leave this to Anshuman ;)) > 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: <stable@vger.kernel.org> > Signed-off-by: Will Deacon <will@kernel.org> I think this could go back as far as the hardware AF/DBM support (v4.3): Fixes: 2f4b829c625e ("arm64: Add support for hardware updates of the access and dirty pte bits") If you limit this fix to 4.14, you probably don't need additional commits. Otherwise, at least this one: 3bbf7157ac66 ("arm64: Convert pte handling from inline asm to using (cmp)xchg") and a slightly more intrusive: 73e86cb03cf2 ("arm64: Move PTE_RDONLY bit handling out of set_pte_at()") We also had some attempts at fixing ptep_set_wrprotect(): 64c26841b349 ("arm64: Ignore hardware dirty bit updates in ptep_set_wrprotect()") Fixed subsequently by: 8781bcbc5e69 ("arm64: mm: Fix pte_mkclean, pte_mkdirty semantics") I have a hope that at some point we'll understand how this all works ;). For this patch: Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
WARNING: multiple messages have this Message-ID (diff)
From: Catalin Marinas <catalin.marinas@arm.com> To: Will Deacon <will@kernel.org> Cc: Yu Zhao <yuzhao@google.com>, Anshuman Khandual <anshuman.khandual@arm.com>, Peter Zijlstra <peterz@infradead.org>, kernel-team@android.com, linux-kernel@vger.kernel.org, stable@vger.kernel.org, linux-mm@kvack.org, Minchan Kim <minchan@kernel.org>, Linus Torvalds <torvalds@linux-foundation.org>, linux-arm-kernel@lists.infradead.org Subject: Re: [PATCH 2/6] arm64: pgtable: Ensure dirty bit is preserved across pte_wrprotect() Date: Mon, 23 Nov 2020 14:22:37 +0000 [thread overview] Message-ID: <20201123142237.GF17833@gaia> (raw) In-Reply-To: <20201120143557.6715-3-will@kernel.org> 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. My assumption at the time was that the caller of pte_wrprotect() already moved the 'dirty' information to the underlying page. Most pte_wrprotect() calls also do a pte_mkclean(). However, it doesn't seem to always be the case (soft-dirty but we don't support it yet). I was worried that we may inadvertently set the dirty bit when doing a pte_wrprotect() on a freshly created pte (not read from memory, for example __split_huge_pmd_locked()) but I think all our __P* and __S* attributes start with a PTE_RDONLY, therefore the pte_hw_dirty() returns false. A test for mm/debug_vm_pgtable.c, something like: for (i = 0, i < ARRAY_SIZE(protection_map); i++) { pte = pfn_pte(pfn, protection_map(i)); WARN_ON(pte_dirty(pte_wrprotect(pte)); } (I'll leave this to Anshuman ;)) > 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: <stable@vger.kernel.org> > Signed-off-by: Will Deacon <will@kernel.org> I think this could go back as far as the hardware AF/DBM support (v4.3): Fixes: 2f4b829c625e ("arm64: Add support for hardware updates of the access and dirty pte bits") If you limit this fix to 4.14, you probably don't need additional commits. Otherwise, at least this one: 3bbf7157ac66 ("arm64: Convert pte handling from inline asm to using (cmp)xchg") and a slightly more intrusive: 73e86cb03cf2 ("arm64: Move PTE_RDONLY bit handling out of set_pte_at()") We also had some attempts at fixing ptep_set_wrprotect(): 64c26841b349 ("arm64: Ignore hardware dirty bit updates in ptep_set_wrprotect()") Fixed subsequently by: 8781bcbc5e69 ("arm64: mm: Fix pte_mkclean, pte_mkdirty semantics") I have a hope that at some point we'll understand how this all works ;). For this patch: Reviewed-by: Catalin Marinas <catalin.marinas@arm.com> _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2020-11-23 14:22 UTC|newest] Thread overview: 91+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-11-20 14:35 [PATCH 0/6] tlb: Fix access and (soft-)dirty bit management Will Deacon 2020-11-20 14:35 ` Will Deacon 2020-11-20 14:35 ` [PATCH 1/6] arm64: pgtable: Fix pte_accessible() Will Deacon 2020-11-20 14:35 ` Will Deacon 2020-11-20 16:03 ` Minchan Kim 2020-11-20 16:03 ` Minchan Kim 2020-11-20 19:53 ` Yu Zhao 2020-11-20 19:53 ` Yu Zhao 2020-11-23 13:27 ` Catalin Marinas 2020-11-23 13:27 ` Catalin Marinas 2020-11-24 10:02 ` Anshuman Khandual 2020-11-24 10:02 ` Anshuman Khandual 2020-11-20 14:35 ` [PATCH 2/6] arm64: pgtable: Ensure dirty bit is preserved across pte_wrprotect() Will Deacon 2020-11-20 14:35 ` Will Deacon 2020-11-20 17:09 ` Minchan Kim 2020-11-20 17:09 ` Minchan Kim 2020-11-23 14:31 ` Catalin Marinas 2020-11-23 14:31 ` Catalin Marinas 2020-11-23 14:22 ` Catalin Marinas [this message] 2020-11-23 14:22 ` Catalin Marinas 2020-11-20 14:35 ` [PATCH 3/6] tlb: mmu_gather: Remove unused start/end arguments from tlb_finish_mmu() Will Deacon 2020-11-20 14:35 ` Will Deacon 2020-11-20 17:20 ` Linus Torvalds 2020-11-20 17:20 ` Linus Torvalds 2020-11-20 17:20 ` Linus Torvalds 2020-11-23 16:48 ` Will Deacon 2020-11-23 16:48 ` Will Deacon 2020-11-20 14:35 ` [PATCH 4/6] mm: proc: Invalidate TLB after clearing soft-dirty page state Will Deacon 2020-11-20 14:35 ` Will Deacon 2020-11-20 15:00 ` Peter Zijlstra 2020-11-20 15:00 ` Peter Zijlstra 2020-11-20 15:09 ` Peter Zijlstra 2020-11-20 15:09 ` Peter Zijlstra 2020-11-20 15:15 ` Will Deacon 2020-11-20 15:15 ` Will Deacon 2020-11-20 15:27 ` Peter Zijlstra 2020-11-20 15:27 ` Peter Zijlstra 2020-11-23 18:23 ` Will Deacon 2020-11-23 18:23 ` Will Deacon 2020-11-20 15:55 ` Minchan Kim 2020-11-20 15:55 ` Minchan Kim 2020-11-23 18:41 ` Will Deacon 2020-11-23 18:41 ` Will Deacon 2020-11-25 22:51 ` Minchan Kim 2020-11-25 22:51 ` Minchan Kim 2020-11-20 20:22 ` Yu Zhao 2020-11-20 20:22 ` Yu Zhao 2020-11-21 2:49 ` Yu Zhao 2020-11-21 2:49 ` Yu Zhao 2020-11-23 19:21 ` Yu Zhao 2020-11-23 19:21 ` Yu Zhao 2020-11-23 22:04 ` Will Deacon 2020-11-23 22:04 ` Will Deacon 2020-11-20 14:35 ` [PATCH 5/6] tlb: mmu_gather: Introduce tlb_gather_mmu_fullmm() Will Deacon 2020-11-20 14:35 ` Will Deacon 2020-11-20 17:22 ` Linus Torvalds 2020-11-20 17:22 ` Linus Torvalds 2020-11-20 17:22 ` Linus Torvalds 2020-11-20 17:31 ` Linus Torvalds 2020-11-20 17:31 ` Linus Torvalds 2020-11-20 17:31 ` Linus Torvalds 2020-11-23 16:48 ` Will Deacon 2020-11-23 16:48 ` Will Deacon 2021-02-01 11:32 ` [tip: core/mm] tlb: mmu_gather: Remove start/end arguments from tlb_gather_mmu() tip-bot2 for Will Deacon 2020-11-22 15:11 ` [tlb] e242a269fa: WARNING:at_mm/mmu_gather.c:#tlb_gather_mmu kernel test robot 2020-11-23 17:51 ` Will Deacon 2020-11-23 17:51 ` Will Deacon 2020-11-20 14:35 ` [PATCH 6/6] mm: proc: Avoid fullmm flush for young/dirty bit toggling Will Deacon 2020-11-20 14:35 ` Will Deacon 2020-11-20 17:41 ` Linus Torvalds 2020-11-20 17:41 ` Linus Torvalds 2020-11-20 17:41 ` Linus Torvalds 2020-11-20 17:45 ` Linus Torvalds 2020-11-20 17:45 ` Linus Torvalds 2020-11-20 17:45 ` Linus Torvalds 2020-11-20 20:40 ` Yu Zhao 2020-11-20 20:40 ` Yu Zhao 2020-11-23 18:35 ` Will Deacon 2020-11-23 18:35 ` Will Deacon 2020-11-23 20:04 ` Yu Zhao 2020-11-23 20:04 ` Yu Zhao 2020-11-23 21:17 ` Will Deacon 2020-11-23 21:17 ` Will Deacon 2020-11-24 1:13 ` Yu Zhao 2020-11-24 1:13 ` Yu Zhao 2020-11-24 14:31 ` Will Deacon 2020-11-24 14:31 ` Will Deacon 2020-11-25 22:01 ` Minchan Kim 2020-11-25 22:01 ` Minchan Kim 2020-11-24 14:46 ` Peter Zijlstra 2020-11-24 14:46 ` Peter Zijlstra
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20201123142237.GF17833@gaia \ --to=catalin.marinas@arm.com \ --cc=anshuman.khandual@arm.com \ --cc=kernel-team@android.com \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-mm@kvack.org \ --cc=minchan@kernel.org \ --cc=peterz@infradead.org \ --cc=stable@vger.kernel.org \ --cc=torvalds@linux-foundation.org \ --cc=will@kernel.org \ --cc=yuzhao@google.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.