Re: BUG: bpf: task hung in lock_sock_nested during sockmap free

On Thu, Aug 20, 2026 at 11:28 AM +09, Kenneth Lee wrote:
> After further analysis, we found that this report is triggered by an
> SK_MSG BPF program repeatedly calling bpf_msg_apply_bytes(msg, 1).
>
> For a message of about 557 KiB, this results in approximately 557,000
> one-byte verdict and push iterations. The TCP BPF send path keeps the
> socket lock while processing these iterations, so deferred
> sock_map_free() waits for the same socket lock.
>
> This appears to be a long lock-held processing path triggered by a valid
> but very unrealistic msg_apply_bytes(1) workload. We believe this behavior
> is benign, but let us know if other behavior is expected.

Thanks for the follow up.

Perhaps that is a convoluted scenario but what caught my attention is
that if you got the hung task notification after ~120 seconds, and it
took ~500k prog runs to trigger it, then something seems quite slow
because we're talking ~240 usec/prog run.

If you have the repro still at hand, it might be worth to take a look at
the CPU trace [1] or a Flamegraph [2] to see where the CPU time goes.

-jkbs

[1] https://perfetto.dev/docs/getting-started/system-tracing
[2] https://www.brendangregg.com/FlameGraphs/cpuflamegraphs.html