Skip to content

Commit 0e2aba6

Browse files
xhackerustcwilldeacon
authored andcommitted
arm64: mm: pass original fault address to handle_mm_fault() in PER_VMA_LOCK block
When reading the arm64's PER_VMA_LOCK support code, I found a bit difference between arm64 and other arch when calling handle_mm_fault() during VMA lock-based page fault handling: the fault address is masked before passing to handle_mm_fault(). This is also different from the usage in mmap_lock-based handling. I think we need to pass the original fault address to handle_mm_fault() as we did in commit 84c5e23 ("arm64: mm: Pass original fault address to handle_mm_fault()"). If we go through the code path further, we can find that the "masked" fault address can cause mismatched fault address between perf sw major/minor page fault sw event and perf page fault sw event: do_page_fault perf_sw_event(PERF_COUNT_SW_PAGE_FAULTS, ..., addr) // orig addr handle_mm_fault mm_account_fault perf_sw_event(PERF_COUNT_SW_PAGE_FAULTS_MAJ, ...) // masked addr Fixes: cd7f176 ("arm64/mm: try VMA lock-based page fault handling first") Signed-off-by: Jisheng Zhang <[email protected]> Reviewed-by: Suren Baghdasaryan <[email protected]> Reviewed-by: Anshuman Khandual <[email protected]> Acked-by: Catalin Marinas <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Will Deacon <[email protected]>
1 parent f3c3762 commit 0e2aba6

File tree

1 file changed

+1
-2
lines changed

1 file changed

+1
-2
lines changed

arch/arm64/mm/fault.c

Lines changed: 1 addition & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -600,8 +600,7 @@ static int __kprobes do_page_fault(unsigned long far, unsigned long esr,
600600
vma_end_read(vma);
601601
goto lock_mmap;
602602
}
603-
fault = handle_mm_fault(vma, addr & PAGE_MASK,
604-
mm_flags | FAULT_FLAG_VMA_LOCK, regs);
603+
fault = handle_mm_fault(vma, addr, mm_flags | FAULT_FLAG_VMA_LOCK, regs);
605604
vma_end_read(vma);
606605

607606
if (!(fault & VM_FAULT_RETRY)) {

0 commit comments

Comments
 (0)