Re: [PATCH bpf-next v2] xsk: Fix circular locking dependency in xsk_notifier

[bot+bpf-ci]

>     xsk: Fix circular locking dependency in xsk_notifier
>
>     syzbot reported a circular locking dependency involving &net->xdp.lock,
>     &xs->mutex, and netdev_lock_ops():
>
>     -> #2 (&net->xdp.lock):
>            xsk_notifier
>            unregister_netdevice_many_notify
>
>     -> #1 (&xs->mutex):
>            xsk_diag_dump
>
>     -> #0 (netdev_lock_ops):
>            xsk_bind

Does this lockdep chain match the syzbot report? Looking at the cited
report (message ID 6a8c9fd9.dbb3a75c.7844.000c.GAE@xxxxxxxxxx), it shows
a four-lock cycle, not three:

    -> #3 (&net->xdp.lock)
           xsk_notifier <- ipvlan_device_event <-
           unregister_netdevice_many_notify <- rtnl_dellink
    -> #2 (&port->pnodes_lock)
           ipvlan_device_event
    -> #1 (&dev_instance_lock_key#23)
           netdev_lock_ops in xsk_bind+0x331 net/xdp/xsk.c:1627
    -> #0 (&xs->mutex)
           xsk_diag_fill net/xdp/xsk_diag.c:113 / xsk_diag_dump:166

    Chain exists of:
      &xs->mutex --> &port->pnodes_lock --> &net->xdp.lock

The report includes &port->pnodes_lock from drivers/net/ipvlan as a
load-bearing link in the chain, which this description omits entirely.

The lock numbering is also reversed. The report uses #3/#2/#1/#0 with
&xs->mutex as #0 (the lock being acquired that triggers the warning),
whereas the commit message renumbers them as #2/#1/#0 and places
netdev_lock_ops as #0 instead.

The causal analysis seems inconsistent too. The commit message states
"In xsk_notifier(), xp_clear_dev() was called while holding &xs->mutex...
this created a nested dependency of &xs->mutex -> netdev_lock_ops."

However, the report attributes the &xs->mutex -> netdev_lock edge to
xsk_bind(), not xsk_notifier(). The report's #1 entry shows:

    -> #1 (&dev_instance_lock_key#23){+.+.}-{4:4}:
           netdev_lock include/linux/netdevice.h:2861 [inline]
           netdev_lock_ops include/net/netdev_lock.h:42 [inline]
           xsk_bind+0x331/0x11d0 net/xdp/xsk.c:1627

Could the commit message be revised to accurately describe the lockdep
chain from the cited report, including all four locks and the correct
code paths that create each dependency?


---
AI reviewed your patch. Please fix the bug or email reply why it's not a bug.
See: https://github.com/kernel-patches/vmtest/blob/master/ci/claude/README.md

CI run summary: https://github.com/kernel-patches/bpf/actions/runs/32990621157