Re: [PATCH bpf] bpf, sockmap: fix lock inversion between stab->lock and sk_callback_lock

[Sechang Lim]

On Tue, Jun 16, 2026 at 06:17:48PM +0800, Jiayuan Chen wrote:
> On 6/16/26 5:11 PM, Sechang Lim wrote:
> > sock_map_update_common() and __sock_map_delete() hold stab->lock and call
> > sock_map_unref() -> sock_map_del_link() under it. sock_map_del_link() takes
> > sk_callback_lock for write to stop the strparser and verdict, giving the
> > lock order stab->lock -> sk_callback_lock.
> >
> > The opposite order comes from an SK_SKB stream parser. On RX,
> > sk_psock_strp_data_ready() holds sk_callback_lock for read while running
> > the parser. The verdict redirects the skb to egress, where a sched_cls
>
>
> The commit message is wrong. A verdict does not redirect to egress
> synchronously — sk_psock_skb_redirect() only queues the skb and
> schedule_delayed_work()s sk_psock_backlog, so egress runs in workqueue
> context, not under sk_callback_lock.

Thanks, you're right. it's the inline ACK, not the redirect. Sorry for
the misleading changelog, I'll fix it in v2.

> > program calls bpf_map_delete_elem() on a sockmap, which takes stab->lock:
> >
> >   WARNING: possible circular locking dependency detected
> >   7.1.0-rc6 Not tainted
> >   ------------------------------------------------------
> >   syz.9.8824 is trying to acquire lock:
> >   (&stab->lock){+.-.}-{3:3}, at: __sock_map_delete net/core/sock_map.c:421
> >   but task is already holding lock:
> >   (clock-AF_INET){++.-}-{3:3}, at: sk_psock_strp_data_ready net/core/skmsg.c:1173
> >
> >   -> #1 (clock-AF_INET){++.-}-{3:3}:
> >          _raw_write_lock_bh
> >          sock_map_del_link net/core/sock_map.c:167
> >          sock_map_unref net/core/sock_map.c:184
> >          sock_map_update_common net/core/sock_map.c:509
> >          sock_map_update_elem_sys net/core/sock_map.c:588
> >          map_update_elem kernel/bpf/syscall.c:1805
> >
> >   -> #0 (&stab->lock){+.-.}-{3:3}:
> >          _raw_spin_lock_bh
> >          __sock_map_delete net/core/sock_map.c:421
> >          sock_map_delete_elem net/core/sock_map.c:452
> >          bpf_prog_06044d24140080b6
> >          tcx_run net/core/dev.c:4451
> >          sch_handle_egress net/core/dev.c:4541
> >          __dev_queue_xmit net/core/dev.c:4808
> >          ...
> >          tcp_bpf_strp_read_sock net/ipv4/tcp_bpf.c:701
>
>
> I guess it is an ACK. What is the actual purpose of a sched_cls 
> program calling
>
> sockmap delete on the TX path of an ACK? If there is no real use case 
> for it, this is
>
> just broken BPF usage, not a kernel bug worth this change.

I don't have a real use case for that exact program. But the verifier
allows sockmap delete from tc, and it deadlocks when the strparser's
socket is concurrently removed from the same map. The fix only moves
sock_map_unref() out from under stab->lock.

Best,
Sechang