On Tue, Sep 09, 2025 at 08:33:27AM -0700, Eric Dumazet wrote:

On Tue, Sep 9, 2025 at 8:19 AM Richard W.M. Jones [off-list ref] wrote:

quoted

On Tue, Sep 09, 2025 at 07:47:09AM -0700, Eric Dumazet wrote:

quoted

On Tue, Sep 9, 2025 at 7:37 AM Jens Axboe [off-list ref] wrote:

quoted

On 9/9/25 8:35 AM, Eric Dumazet wrote:

quoted

On Tue, Sep 9, 2025 at 7:04 AM Eric Dumazet [off-list ref] wrote:

quoted

On Tue, Sep 9, 2025 at 6:32 AM Richard W.M. Jones [off-list ref] wrote:

quoted

On Tue, Sep 09, 2025 at 01:22:43PM +0000, Eric Dumazet wrote:

quoted

Recently, syzbot started to abuse NBD with all kinds of sockets.

Commit cf1b2326b734 ("nbd: verify socket is supported during setup")
made sure the socket supported a shutdown() method.

Explicitely accept TCP and UNIX stream sockets.

I'm not clear what the actual problem is, but I will say that libnbd &
nbdkit (which are another NBD client & server, interoperable with the
kernel) we support and use NBD over vsock[1].  And we could support
NBD over pretty much any stream socket (Infiniband?) [2].

[1] https://libguestfs.org/nbd_aio_connect_vsock.3.html
    https://libguestfs.org/nbdkit-service.1.html#AF_VSOCK
[2] https://libguestfs.org/nbd_connect_socket.3.html

TCP and Unix domain sockets are by far the most widely used, but I
don't think it's fair to exclude other socket types.

If we have known and supported socket types, please send a patch to add them.

I asked the question last week and got nothing about vsock or other types.

https://lore.kernel.org/netdev/CANn89iLNFHBMTF2Pb6hHERYpuih9eQZb6A12+ndzBcQs_kZoBA@mail.gmail.com/ (local)

For sure, we do not want datagram sockets, RAW, netlink, and many others.

BTW vsock will probably fire lockdep warnings, I see GFP_KERNEL
being used in net/vmw_vsock/virtio_transport.c

CC-ing Stefan & Stefano.  Myself, I'm only using libnbd
(ie. userspace) over vsock, not the kernel client.

Thanks Rich for cceing me!

quoted

quoted

quoted

quoted

So you will have to fix this.

How we should fix that?

IIUC GFP_KERNEL in virtio_transport.c is used only by workqueue's 
functions, but we have GFP_ATOMIC in the fast path that can be called 
when the user is sending a packet.

This is basically the driver for the virtio-vsock device that can 
allocates extra buffers to be exposed to the device.
In this case the allocation can happen in virtqueue_add_sgs() for virtio 
indirect buffer, that IIRC virtio-vsock is not using currently (but we 
don't know in the future).

In any case, we use GFP_KERNEL also in virtio_transport_common.c to 
allocate the sk_buff, so that should be the same issue.

Thanks,
Stefano