Skip to contentSkip to conversation

Patch "arm64: Implement ptep_set_access_flags() for hardware AF/DBM" has been added to the 4.4-stable tree

PATCH [email protected] 1 participant 1 message May 29, 2016

Subsystems (2)
lore
Share & tools
lore

[email protected]

author maintainer Applied
#0 lore raw

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 66dbd6e61a526ae7d11a208238ae2c17e5cacb6b Mon 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.

Fixes 2f4b829c625e ("arm64: Add support for hardware updates of the access and dirty pte bits")
Cc Will Deacon <[email protected]>
[will: reworded comment]
---
 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