Re: [PATCH bpf-next v3 5/6] bpf: Atomically update PTE and range tree in arena VM fault handler

["Alexei Starovoitov" <alexei.starovoitov@gmail.com>]

On Wed, Sep 23, 2026 at 07:11 PM Emil Tsalapatis <emil@etsalapatis.com> wrote:
> There is no way to protect the PTE installation and the range tree
> modification simultaneously, because we cannot nest the synchronization
> primitives for their respective critical sections. PTE allocation
> may require allocations due to PTE reclamation, and its spinlock
> becomes sleepable under PREEMPT_RT. Thus we cannot do this operation
> while holding the range tree spinlock. There is no public API for
> manually taking this spinlock, so we nest the range tree operation
> inside it.

__do_fault() locks the page returned by ->fault() before finish_fault()
installs the pte. That's how filemap_fault() is synchronized with
truncate.
can arena_vm_fault() lock the page, recheck vmalloc_to_page() and
return VM_FAULT_LOCKED, and the free path do
lock_page(); unlock_page(); before zap_pages() ?

[...]
>  out:
> -	page_ref_add(page, 1);
> +	/* Reserve the page while installing its user PTE without the arena lock. */
> +	bpf_map_memcg_enter(&arena->map, &old_memcg, &new_memcg);
> +	unavail_node = range_tree_set_unavail(&arena->rt, vmf->pgoff, 1);
> +	bpf_map_memcg_exit(old_memcg, new_memcg);
>  	raw_res_spin_unlock_irqrestore(&arena->spinlock, flags);
> -	if (new_page)
> +
> +	if (new_page) {
>  		free_pages_nolock(new_page, 0);
> -	vmf->page = page;
> -	return 0;
> +		new_page = NULL;
> +	}
> +
> +	/* If we couldn't mark the page unavailable, retry. */
> +	if (IS_ERR(unavail_node)) {
> +		ret = PTR_ERR(unavail_node);
> +		if (ret == -EAGAIN)
> +			goto retry;
> +		return VM_FAULT_SIGBUS;
> +	}

The race needs user space to access the page while bpf prog is
freeing it.
With this patch every user fault, including the one on a page that
bpf prog already allocated, does kmalloc_nolock() of a range node.
It cannot reclaim, so at memory.max the process gets SIGBUS on
a valid page. That's what commit c7cd8be3d72f fixed.
Two threads touching the same page for the first time: the 2nd one
gets -EAGAIN and spins in VM_FAULT_RETRY until the 1st is done.