Re: [PATCH] bpf: disable lockdep while running BPF on lock_release

On Tue, Aug 4, 2026 at 4:34=E2=80=AFPM NeilBrown <[email protected]> wrote:
> I know close enough to nothing about BPF or trace points...
>
> Can BPF programs ever block waiting for a lock that is held across a
> tracepoint?
I investigate this and I think the answer could splits in two:

Mutex (sleeping locks): no, this is prevented at verification time. A
BPF program attached to a tracepoint is non-sleepable --
can_be_sleepable() returns false for BPF_PROG_TYPE_TRACEPOINT, so the
verifier rejects any sleeping helper; and at runtime it runs under
rcu_read_lock() with cant_sleep(). It cannot block on a mutex held
across the tracepoint.

Spinlock: yes, in principle. Spinlocks busy-wait rather than sleep, so
the mutex protection does not apply. BPF programs do take spinlocks --
each map lookup/update/delete takes the map's bucket lock, and
bpf_spin_lock is a spinlock -- so a program attached to a tracepoint
held across a spinlock can spin on another spinlock, and if those form a
cycle (or are the same lock) it is a real deadlock.

That is exactly the hazard BPF already hardened its own locks against:
the hashtab bucket lock and bpf_spin_lock detect recursive acquisition
and return an error instead of deadlocking (rqspinlock, succeeding the
map_locked approach in 20b6cc34ea74). The rhashtable bucket bitlock has
no such protection -- which is the gap I think.

quanyeyang
> If so, then attaching a BPF program to that trace point could
> trivially cause a deadlock.
> If not - then how is that ensured?
>
> Thanks,
> NeilBrown