summaryrefslogtreecommitdiff
path: root/lib/test_uuid.c
diff options
context:
space:
mode:
authorWill Deacon <will.deacon@arm.com>2017-12-12 10:48:54 +0000
committerWill Deacon <will.deacon@arm.com>2017-12-12 11:42:24 +0000
commit86c9e8126e9fbcbf06c36e285168b880369a537c (patch)
tree91889a0eaf4e732fa83a17f9d9e55c192c25574a /lib/test_uuid.c
parent8781bcbc5e69d7da69e84c7044ca0284848d5d01 (diff)
downloadlinux-86c9e8126e9fbcbf06c36e285168b880369a537c.tar.gz
linux-86c9e8126e9fbcbf06c36e285168b880369a537c.tar.bz2
linux-86c9e8126e9fbcbf06c36e285168b880369a537c.zip
arm64: mm: Fix false positives in set_pte_at access/dirty race detection
Jiankang reports that our race detection in set_pte_at is firing when copying the page tables in dup_mmap as a result of a fork(). In this situation, the page table isn't actually live and so there is no way that we can race with a concurrent update from the hardware page table walker. This patch reworks the race detection so that we require either the mm to match the current active_mm (i.e. currently installed in our TTBR0) or the mm_users count to be greater than 1, implying that the page table could be live in another CPU. The mm_users check might still be racy, but we'll avoid false positives and it's not realistic to validate that all the necessary locks are held as part of this assertion. Cc: Yisheng Xie <xieyisheng1@huawei.com> Reported-by: Jiankang Chen <chenjiankang1@huawei.com> Tested-by: Jiankang Chen <chenjiankang1@huawei.com> Signed-off-by: Will Deacon <will.deacon@arm.com>
Diffstat (limited to 'lib/test_uuid.c')
0 files changed, 0 insertions, 0 deletions