Catalin Marinas 66dbd6e61a arm64: Implement ptep_set_access_flags() for hardware AF/DBM
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")
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Reported-by: Ming Lei <tom.leiming@gmail.com>
Tested-by: Julien Grall <julien.grall@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
Cc: <stable@vger.kernel.org> # 4.3+
[will: reworded comment]
Signed-off-by: Will Deacon <will.deacon@arm.com>
2016-04-15 18:06:09 +01:00
..
2015-11-04 14:47:13 -08:00
2016-01-12 20:46:53 +02:00
2014-04-18 11:40:33 +02:00
2015-10-28 19:09:17 +00:00
2016-03-24 19:13:59 -07:00
2012-09-17 13:42:21 +01:00
2016-03-17 20:03:47 -07:00
2016-03-20 15:08:45 -07:00
2014-11-05 09:03:25 +01:00
2015-07-27 11:08:42 +01:00
2012-09-17 13:42:21 +01:00
2012-09-17 13:42:04 +01:00
2016-03-04 18:19:17 +00:00
2014-09-25 15:35:41 +01:00
2016-03-17 20:03:47 -07:00
2012-09-17 13:41:56 +01:00
2016-02-24 14:57:27 +00:00
2016-02-16 15:10:46 +00:00
2015-05-19 15:27:42 +01:00
2016-03-02 15:49:28 +00:00
2014-11-28 10:24:59 +00:00
2016-04-15 18:06:06 +01:00
2015-10-12 17:46:36 +01:00
2014-07-10 11:06:00 +01:00
2015-10-14 13:51:41 +01:00
2015-10-14 13:51:41 +01:00
2012-09-17 13:42:09 +01:00
2012-09-17 13:42:09 +01:00
2016-04-15 18:06:07 +01:00