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>
Showing
Please register or sign in to comment