On Fri, Oct 04, 2024 at 04:10:31PM +0000, Bernard Metzler wrote:
> Could one please help me to understand this situation?
> cma.c:5354
>
> mutex_lock(&lock);
> list_add_tail(&cma_dev->list, &dev_list);
> list_for_each_entry(id_priv, &listen_any_list, listen_any_item) {
> ret = cma_listen_on_dev(id_priv, cma_dev, &to_destroy);
> if (ret)
> goto free_listen;
> }
> mutex_unlock(&lock);
>
> siw_cm.c:1776
> sock_set_reuseaddr(s->sk);
>
> ...which calls lock_sock(sk) on a feshly created socket.
I think this is a smc bug, and lockdep is getting confused about what
to report due to all the different locks.
smc_setsockopt() eventually in ip_setsockopt() does:
mutex_lock(&smc->clcsock_release_lock);
if (needs_rtnl)
rtnl_lock();
sockopt_lock_sock(sk);
mutex_unlock(&smc->clcsock_release_lock);
smc_sendmsg() does
lock_sock(sk);
mutex_lock(&smc->clcsock_release_lock);
Which is classic deadlock locking.
That the CMA gets involved here seems like wrong reporting because
syzkaller put those lock chains into it.
I guess this is a dup of
https://lore.kernel.org/netdev/00000000000093078f0622583e6e@xxxxxxxxxx/T/
Or at least that should be fixed before looking at this
Jason
