Re: [PATCH bpf 1/2] bpf: Use dedicated workqueue for freeing BPF programs

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

On Sun, Nov 01, 2026 at 11:34 PM Emil Tsalapatis <emil@etsalapatis.com> wrote:
> BPF free workers can exhaust a CPU's system workqueue active slots while
> waiting for pack_mutex. The worker holding pack_mutex then waits for a
> vmalloc purge helper on that same queue, which cannot run until a slot
> is freed.

This doesn't apply to bpf tree.
Commit 4eaf4d71b91a ("bpf: Keep the symbols of a program until it has
ended") moved bpf_jit_free() into bpf_prog_free_images().
bpf_prog_free_deferred() queues it with
queue_rcu_work(system_percpu_wq, &aux->rwork).
So with this patch the pack_mutex waiters are still on system_percpu_wq.

__bpf_tramp_image_put_deferred() has the same problem.
It runs from schedule_work(), and arch_free_bpf_trampoline() calls
bpf_prog_pack_free().

Let's move all three to the new wq in one patch?

> Fixes: 6b88aaec81db ("x86/bpf: Enable EXECMEM_ROX_CACHE for BPF allocations")

The ROX cache is not the cause.
Without it bpf_jit_free_exec() is vfree() of a VM_FLUSH_RESET_PERMS area.
vm_reset_perms() calls _vm_unmap_aliases() and gets to the same
flush_work(), also under pack_mutex.
That's every arch with bpf_prog_pack since
commit 72210662c5a2 ("mm: vmalloc: offload free_vmap_area_lock lock").

> +	bpf_prog_free_wq = alloc_workqueue("bpf_prog_free", WQ_UNBOUND, 0);

0 means 1024. That's up to 1024 kworkers that sleep on pack_mutex.
max_active = 1 like cgroup_bpf_destroy_wq ?

pw-bot: cr