Re: [PATCH bpf-next 0/5] bpf: BPF specific memory allocator.

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

On Mon, Jun 27, 2022 at 5:17 PM Christoph Lameter <cl@gentwo.de> wrote:
>
> > From: Alexei Starovoitov <ast@kernel.org>
> >
> > Introduce any context BPF specific memory allocator.
> >
> > Tracing BPF programs can attach to kprobe and fentry. Hence they
> > run in unknown context where calling plain kmalloc() might not be safe.
> > Front-end kmalloc() with per-cpu per-bucket cache of free elements.
> > Refill this cache asynchronously from irq_work.
>
> GFP_ATOMIC etc is not going to work for you?

slab_alloc_node->slab_alloc->local_lock_irqsave
kprobe -> bpf prog -> slab_alloc_node -> deadlock.
In other words, the slow path of slab allocator takes locks.
Which makes it unsafe to use from tracing bpf progs.
That's why we preallocated all elements in bpf maps,
so there are no calls to mm or rcu logic.
bpf specific allocator cannot use locks at all.
try_lock approach could have been used in alloc path,
but free path cannot fail with try_lock.
Hence the algorithm in this patch is purely lockless.
bpf prog can attach to spin_unlock_irqrestore and
safely do bpf_mem_alloc.