Re: [PATCH bpf-next] arm64: mm: Complete the PTE store in ptep_try_set()

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] The patch uses `__set_pte_complete()` in `ptep_try_set()`, which incorrectly defers architectural PTE barriers if a synchronous BPF fault interrupts a lazy MMU block, leading to an infinite page fault livelock.
--

commit 3da2cf1409cd9f964e0879e7b2ee1aaae71958ab
Author: Tejun Heo <tj@kernel.org>

arm64: mm: Complete the PTE store in ptep_try_set()

This commit updates ptep_try_set() to call __set_pte_complete() after
successfully setting a new PTE via try_cmpxchg(). This mirrors the behavior
in __set_pte() to ensure architectural barriers are issued for valid kernel
PTEs on arm64.

Link: https://lore.kernel.org/all/aiRFcz78QTZdIHHB@arm.com/

> diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm/pgtable.h
> index 984f0502c9d0f..9f5d75e736919 100644
> --- a/arch/arm64/include/asm/pgtable.h
> +++ b/arch/arm64/include/asm/pgtable.h
> @@ -1838,7 +1838,11 @@ static inline bool ptep_try_set(pte_t *ptep, pte_t new_pte)
>  {
>  	pteval_t old = 0;
>  
> -	return try_cmpxchg(&pte_val(*ptep), &old, pte_val(new_pte));
> +	if (!try_cmpxchg(&pte_val(*ptep), &old, pte_val(new_pte)))
> +		return false;
> +
> +	__set_pte_complete(new_pte);

[Severity: High]
Does calling __set_pte_complete() here risk deferring required architectural
barriers during synchronous BPF arena page faults like
bpf_arena_kernel_fault()?

If a BPF program triggers while the interrupted task is inside a lazy MMU
block (like zap_pte_range()), the kprobe runs as a synchronous debug
exception, so in_interrupt() is false.

__set_pte_complete() delegates to queue_pte_barriers(), which defers the
hardware barriers by setting TIF_LAZY_MMU_PENDING if
is_lazy_mmu_mode_active() returns true. Since in_interrupt() is false,
is_lazy_mmu_mode_active() will evaluate to true.

Because the required dsb is deferred, the fault handler can return without
the memory system observing the new PTE. The CPU then retries the faulting
instruction, which faults again, resulting in an infinite page fault loop.

> +	return true;
>  }
>  #define ptep_try_set ptep_try_set

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/088f52fd25860ca961449d53f91b214a@kernel.org?part=1