Patch "arm64: Implement ptep_set_access_flags() for hardware AF/DBM" has been added to the 4.4-stable tree
Subsystems (2)
This is a note to let you know that I've just added the patch titled
arm64: Implement ptep_set_access_flags() for hardware AF/DBM
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
arm64-implement-ptep_set_access_flags-for-hardware-af-dbm.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree, please let <[email protected]> know about it.
Quoted 1 line
From
66dbd6e61a526ae7d11a208238ae2c17e5cacb6bMon Sep 17 00:00:00 2001
From: Catalin Marinas <[email protected]>
Date: Wed, 13 Apr 2016 16:01:22 +0100
Subject: arm64: Implement ptep_set_access_flags() for hardware AF/DBM
From: Catalin Marinas <[email protected]>
commit 66dbd6e61a526ae7d11a208238ae2c17e5cacb6b upstream.
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.
--- arch/arm64/include/asm/pgtable.h | 5 +++ arch/arm64/mm/fault.c | 50 +++++++++++++++++++++++++++++++++++++++ 2 files changed, 55 insertions(+)
arch/arm64/include/asm/pgtable.h +5 -0
@@ -538,6 +538,11 @@ static inline pmd_t pmd_modify(pmd_t pmd }#ifdef CONFIG_ARM64_HW_AFDBM +#define __HAVE_ARCH_PTEP_SET_ACCESS_FLAGS +extern int ptep_set_access_flags (struct vm_area_struct *vma, +unsigned long address,pte_t *ptep, +pte_t entry,int dirty); +/* * Atomic pte/pmd modifications. */
arch/arm64/mm/fault.c +50 -0
56 lines not on this page · raw message
Patches currently in stable-queue which might be from [email protected] are
queue-4.4/arm64-fix-typo-in-the-pmdp_huge_get_and_clear-definition.patch queue-4.4/arm64-implement-ptep_set_access_flags-for-hardware-af-dbm.patch queue-4.4/arm64-implement-pmdp_set_access_flags-for-hardware-af-dbm.patch queue-4.4/arm64-ensure-pmd_present-returns-false-after-pmd_mknotpresent.patch