Re: [PATCH bpf-next] bpf: arena: fix mmap_lock deadlock on arena lock failure

["Kumar Kartikeya Dwivedi" <memxor@gmail.com>]

On Mon Aug 3, 2026 at 3:21 AM CEST, Kumar Kartikeya Dwivedi wrote:
> On Tue Jul 28, 2026 at 8:05 AM CEST, Jiayuan Chen wrote:
>> Reported by the Sashiko AI review.
>>
>> arena_vm_fault() returns VM_FAULT_RETRY when it can't take
>> arena->spinlock, but it never took mmap_lock. The fault path assumes a
>> VM_FAULT_RETRY handler already dropped mmap_lock and re-takes it on the
>> retry, so mmap_lock gets taken twice and can deadlock:
>>
>> 	do_user_addr_fault()
>> 	{
>> 		fault = handle_mm_fault(...);   // calls arena_vm_fault()
>> 		if (fault & VM_FAULT_RETRY)
>> 			goto retry;   // re-locks mmap_lock
>> 		mmap_read_unlock(mm);
>> 	}
>>
>> Return VM_FAULT_SIGBUS instead, for two reasons:
>>
>> 1. We could keep VM_FAULT_RETRY, but then we'd have to drop the fault
>>    lock first and cap the retry ourselves, the way __folio_lock_or_retry()
>>    does.
>>
>> 2. A failed raw_res_spin_lock_irqsave() already means a possible deadlock
>>    was detected, so retrying just hits the same lock again.
>>
>> So returning VM_FAULT_RETRY here is overkill.
>>
>> Fixes: b8467290edab ("bpf: arena: make arena kfuncs any context safe")
>> Signed-off-by: Jiayuan Chen <jiayuan.chen@linux.dev>
>>
>> ---
>> target to bpf-next since I think it is moderate.
>> ---
>
> This looks ok to me, but after staring at this function for longer, I think all
> kinds of non-recoverable errors should be using VM_FAULT_SIGBUS vs SIGSEGV.
>
> The only case with SIGSEGV should be the flag based request to disable
> allocation on lazy faults. That should include the scratch page case, since it
> represents a hole.
>
> SIGSEGV: BPF_F_SEGV_ON_FAULT, scratch page.
> SIGBUS: lock acquisition failure, range-tree failures, page allocation failure,
> kernel PTE install failure.
>
> All of these SIGBUS are almost improbable, but I think it would be cleaner to
> keep semantics clear.
>
> Could you follow up with this change? I applied this one for now.
>

For the scratch page case, I think we do SIGSEGV when the BPF_F_SEGV_ON_FAULT
flag is set, but SIGBUS otherwise there too, since we could but choose not to
lazy allocate a page due to the program's error / bug.