Re: Re: Re: possible deadlock in cma_netdev_callback

From: Bernard Metzler
Date: Fri Feb 28 2020 - 11:42:17 EST


-----"Jason Gunthorpe" <jgg@xxxxxxxx> wrote: -----

>To: "Bernard Metzler" <BMT@xxxxxxxxxxxxxx>
>From: "Jason Gunthorpe" <jgg@xxxxxxxx>
>Date: 02/28/2020 02:35PM
>Cc: "syzbot" <syzbot+55de90ab5f44172b0c90@xxxxxxxxxxxxxxxxxxxxxxxxx>,
>chuck.lever@xxxxxxxxxx, dledford@xxxxxxxxxx, leon@xxxxxxxxxx,
>linux-kernel@xxxxxxxxxxxxxxx, linux-rdma@xxxxxxxxxxxxxxx,
>netdev@xxxxxxxxxxxxxxx, parav@xxxxxxxxxxxx,
>syzkaller-bugs@xxxxxxxxxxxxxxxx, willy@xxxxxxxxxxxxx
>Subject: [EXTERNAL] Re: Re: possible deadlock in cma_netdev_callback
>
>On Fri, Feb 28, 2020 at 01:05:53PM +0000, Bernard Metzler wrote:
>>
>> >To: "Bernard Metzler" <BMT@xxxxxxxxxxxxxx>
>> >From: "Jason Gunthorpe" <jgg@xxxxxxxx>
>> >Date: 02/27/2020 05:46PM
>> >Cc: "syzbot"
><syzbot+55de90ab5f44172b0c90@xxxxxxxxxxxxxxxxxxxxxxxxx>,
>> >chuck.lever@xxxxxxxxxx, dledford@xxxxxxxxxx, leon@xxxxxxxxxx,
>> >linux-kernel@xxxxxxxxxxxxxxx, linux-rdma@xxxxxxxxxxxxxxx,
>> >netdev@xxxxxxxxxxxxxxx, parav@xxxxxxxxxxxx,
>> >syzkaller-bugs@xxxxxxxxxxxxxxxx, willy@xxxxxxxxxxxxx
>> >Subject: [EXTERNAL] Re: possible deadlock in cma_netdev_callback
>> >
>> >On Thu, Feb 27, 2020 at 04:21:21PM +0000, Bernard Metzler wrote:
>> >>
>> >> >To: "Bernard Metzler" <BMT@xxxxxxxxxxxxxx>
>> >> >From: "Jason Gunthorpe" <jgg@xxxxxxxx>
>> >> >Date: 02/27/2020 04:53PM
>> >> >Cc: "syzbot"
>> ><syzbot+55de90ab5f44172b0c90@xxxxxxxxxxxxxxxxxxxxxxxxx>,
>> >> >chuck.lever@xxxxxxxxxx, dledford@xxxxxxxxxx, leon@xxxxxxxxxx,
>> >> >linux-kernel@xxxxxxxxxxxxxxx, linux-rdma@xxxxxxxxxxxxxxx,
>> >> >netdev@xxxxxxxxxxxxxxx, parav@xxxxxxxxxxxx,
>> >> >syzkaller-bugs@xxxxxxxxxxxxxxxx, willy@xxxxxxxxxxxxx
>> >> >Subject: [EXTERNAL] Re: possible deadlock in
>cma_netdev_callback
>> >> >
>> >> >On Thu, Feb 27, 2020 at 10:11:13AM +0000, Bernard Metzler
>wrote:
>> >> >
>> >> >> Thanks for letting me know! Hmm, we cannot use RCU locks
>since
>> >> >> we potentially sleep. One solution would be to create a list
>> >> >> of matching interfaces while under lock, unlock and use that
>> >> >> list for calling siw_listen_address() (which may sleep),
>> >> >> right...?
>> >> >
>> >> >Why do you need to iterate over addresses anyhow? Shouldn't the
>> >> >listen
>> >> >just be done with the address the user gave and a BIND DEVICE
>to
>> >the
>> >> >device siw is connected to?
>> >>
>> >> The user may give a wildcard local address, so we'd have
>> >> to bind to all addresses of that device...
>> >
>> >AFAIK a wild card bind using BIND DEVICE works just fine?
>> >
>> >Jason
>> >
>> Thanks Jason, absolutely! And it makes things so easy...
>
>Probably check to confirm, it just my memory..
>
>Jason
>
Well, right, marking a socket via setsockopt SO_BINDTODEVICE
does not work - I get -EPERM. Maybe works only from user land
since the ifname gets copied in from there.

What I tested as working is nailing the scope of wildcard
listen via:
s->sk->sk_bound_dev_if = netdev->ifindex;

Without doing it, wildcard listen would end up covering all
interfaces, even if siw is not attached to some. Also, if siw is
attached to more than one interface, only the first bind call
works of course (for wildcard, the rdma_cm calls me for all
interfaces siw is attached to). So without binding to a
device it is not working.

I am not sure what is the right way of limiting the scope
of a socket to one interface in kernel mode. Is above line
the way to go, or do I miss an interface to do such things?
Anybody could help?

Thanks very much!
Bernard.