| Message ID | 20191119110121.14480-5-sgarzare@redhat.com |
|---|---|
| State | Changes Requested |
| Delegated to: | David Miller |
| Headers | show |
| Series | vsock: add local transport support | expand |
From: Stefano Garzarella <sgarzare@redhat.com> Date: Tue, 19 Nov 2019 12:01:19 +0100 > +static int vsock_loopback_cancel_pkt(struct vsock_sock *vsk) > +{ > + struct vsock_loopback *vsock; > + struct virtio_vsock_pkt *pkt, *n; > + int ret; > + LIST_HEAD(freeme); Reverse christmas tree ordering of local variables here please.
On Tue, Nov 19, 2019 at 05:15:01PM -0800, David Miller wrote: > From: Stefano Garzarella <sgarzare@redhat.com> > Date: Tue, 19 Nov 2019 12:01:19 +0100 > > > +static int vsock_loopback_cancel_pkt(struct vsock_sock *vsk) > > +{ > > + struct vsock_loopback *vsock; > > + struct virtio_vsock_pkt *pkt, *n; > > + int ret; > > + LIST_HEAD(freeme); > > Reverse christmas tree ordering of local variables here please. > Sure, I'll fix in the v2. Thanks, Stefano
On Tue, Nov 19, 2019 at 12:01:19PM +0100, Stefano Garzarella wrote: Ideas for long-term changes below. Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> > diff --git a/MAINTAINERS b/MAINTAINERS > index 760049454a23..c2a3dc3113ba 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -17239,6 +17239,7 @@ F: net/vmw_vsock/diag.c > F: net/vmw_vsock/af_vsock_tap.c > F: net/vmw_vsock/virtio_transport_common.c > F: net/vmw_vsock/virtio_transport.c > +F: net/vmw_vsock/vsock_loopback.c > F: drivers/net/vsockmon.c > F: drivers/vhost/vsock.c > F: tools/testing/vsock/ At this point you are most active in virtio-vsock and I am reviewing patches on a best-effort basis. Feel free to add yourself as maintainer. > diff --git a/net/vmw_vsock/vsock_loopback.c b/net/vmw_vsock/vsock_loopback.c > new file mode 100644 > index 000000000000..3d1c1a88305f > --- /dev/null > +++ b/net/vmw_vsock/vsock_loopback.c > @@ -0,0 +1,217 @@ > +// SPDX-License-Identifier: GPL-2.0-only > +/* > + * loopback transport for vsock using virtio_transport_common APIs > + * > + * Copyright (C) 2013-2019 Red Hat, Inc. > + * Author: Asias He <asias@redhat.com> > + * Stefan Hajnoczi <stefanha@redhat.com> > + * Stefano Garzarella <sgarzare@redhat.com> > + * > + */ > +#include <linux/spinlock.h> > +#include <linux/module.h> > +#include <linux/list.h> > +#include <linux/virtio_vsock.h> Is it time to rename the generic functionality in virtio_transport_common.c? This doesn't have anything to do with virtio :). > + > +static struct workqueue_struct *vsock_loopback_workqueue; > +static struct vsock_loopback *the_vsock_loopback; the_vsock_loopback could be a static global variable (not a pointer) and vsock_loopback_workqueue could also be included in the struct. The RCU pointer is really a way to synchronize vsock_loopback_send_pkt() and vsock_loopback_cancel_pkt() with module exit. There is no other reason for using a pointer. It's cleaner to implement the synchronization once in af_vsock.c (or virtio_transport_common.c) instead of making each transport do it. Maybe try_module_get() and related APIs provide the necessary semantics so that core vsock code can hold the transport module while it's being used to send/cancel a packet. > +MODULE_ALIAS_NETPROTO(PF_VSOCK); Why does this module define the alias for PF_VSOCK? Doesn't another module already define this alias?
On Thu, Nov 21, 2019 at 09:34:58AM +0000, Stefan Hajnoczi wrote: > On Tue, Nov 19, 2019 at 12:01:19PM +0100, Stefano Garzarella wrote: > > Ideas for long-term changes below. > > Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> > Thanks for reviewing! > > diff --git a/MAINTAINERS b/MAINTAINERS > > index 760049454a23..c2a3dc3113ba 100644 > > --- a/MAINTAINERS > > +++ b/MAINTAINERS > > @@ -17239,6 +17239,7 @@ F: net/vmw_vsock/diag.c > > F: net/vmw_vsock/af_vsock_tap.c > > F: net/vmw_vsock/virtio_transport_common.c > > F: net/vmw_vsock/virtio_transport.c > > +F: net/vmw_vsock/vsock_loopback.c > > F: drivers/net/vsockmon.c > > F: drivers/vhost/vsock.c > > F: tools/testing/vsock/ > > At this point you are most active in virtio-vsock and I am reviewing > patches on a best-effort basis. Feel free to add yourself as > maintainer. > Sure, I'd be happy to maintain it. > > diff --git a/net/vmw_vsock/vsock_loopback.c b/net/vmw_vsock/vsock_loopback.c > > new file mode 100644 > > index 000000000000..3d1c1a88305f > > --- /dev/null > > +++ b/net/vmw_vsock/vsock_loopback.c > > @@ -0,0 +1,217 @@ > > +// SPDX-License-Identifier: GPL-2.0-only > > +/* > > + * loopback transport for vsock using virtio_transport_common APIs > > + * > > + * Copyright (C) 2013-2019 Red Hat, Inc. > > + * Author: Asias He <asias@redhat.com> > > + * Stefan Hajnoczi <stefanha@redhat.com> > > + * Stefano Garzarella <sgarzare@redhat.com> > > + * > > + */ > > +#include <linux/spinlock.h> > > +#include <linux/module.h> > > +#include <linux/list.h> > > +#include <linux/virtio_vsock.h> > > Is it time to rename the generic functionality in > virtio_transport_common.c? This doesn't have anything to do with virtio > :). > Completely agree, new transports could use it to handle the protocol without reimplementing things already done. > > + > > +static struct workqueue_struct *vsock_loopback_workqueue; > > +static struct vsock_loopback *the_vsock_loopback; > > the_vsock_loopback could be a static global variable (not a pointer) and > vsock_loopback_workqueue could also be included in the struct. > > The RCU pointer is really a way to synchronize vsock_loopback_send_pkt() > and vsock_loopback_cancel_pkt() with module exit. There is no other > reason for using a pointer. > > It's cleaner to implement the synchronization once in af_vsock.c (or > virtio_transport_common.c) instead of making each transport do it. > Maybe try_module_get() and related APIs provide the necessary semantics > so that core vsock code can hold the transport module while it's being > used to send/cancel a packet. Right, the module cannot be unloaded until open sockets, so here the synchronization is not needed. The synchronization come from virtio-vsock device that can be hot-unplugged while sockets are still open, but that can't happen here. I will remove the pointers and RCU in the v2. Can I keep your R-b or do you prefer to watch v2 first? > > > +MODULE_ALIAS_NETPROTO(PF_VSOCK); > > Why does this module define the alias for PF_VSOCK? Doesn't another > module already define this alias? It is a way to load this module when PF_VSOCK is starting to be used. MODULE_ALIAS_NETPROTO(PF_VSOCK) is already defined in vmci_transport and hyperv_transport. IIUC it is used for the same reason. In virtio_transport we don't need it because it will be loaded when the PCI device is discovered. Do you think there's a better way? Should I include the vsock_loopback transport directly in af_vsock without creating a new module? Thanks, Stefano
On Thu, Nov 21, 2019 at 10:59:48AM +0100, Stefano Garzarella wrote: > On Thu, Nov 21, 2019 at 09:34:58AM +0000, Stefan Hajnoczi wrote: > > On Tue, Nov 19, 2019 at 12:01:19PM +0100, Stefano Garzarella wrote: > > > > Ideas for long-term changes below. > > > > Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> > > > > Thanks for reviewing! > > > > diff --git a/MAINTAINERS b/MAINTAINERS > > > index 760049454a23..c2a3dc3113ba 100644 > > > --- a/MAINTAINERS > > > +++ b/MAINTAINERS > > > @@ -17239,6 +17239,7 @@ F: net/vmw_vsock/diag.c > > > F: net/vmw_vsock/af_vsock_tap.c > > > F: net/vmw_vsock/virtio_transport_common.c > > > F: net/vmw_vsock/virtio_transport.c > > > +F: net/vmw_vsock/vsock_loopback.c > > > F: drivers/net/vsockmon.c > > > F: drivers/vhost/vsock.c > > > F: tools/testing/vsock/ > > > > At this point you are most active in virtio-vsock and I am reviewing > > patches on a best-effort basis. Feel free to add yourself as > > maintainer. > > > > Sure, I'd be happy to maintain it. > > > > diff --git a/net/vmw_vsock/vsock_loopback.c b/net/vmw_vsock/vsock_loopback.c > > > new file mode 100644 > > > index 000000000000..3d1c1a88305f > > > --- /dev/null > > > +++ b/net/vmw_vsock/vsock_loopback.c > > > @@ -0,0 +1,217 @@ > > > +// SPDX-License-Identifier: GPL-2.0-only > > > +/* > > > + * loopback transport for vsock using virtio_transport_common APIs > > > + * > > > + * Copyright (C) 2013-2019 Red Hat, Inc. > > > + * Author: Asias He <asias@redhat.com> > > > + * Stefan Hajnoczi <stefanha@redhat.com> > > > + * Stefano Garzarella <sgarzare@redhat.com> > > > + * > > > + */ > > > +#include <linux/spinlock.h> > > > +#include <linux/module.h> > > > +#include <linux/list.h> > > > +#include <linux/virtio_vsock.h> > > > > Is it time to rename the generic functionality in > > virtio_transport_common.c? This doesn't have anything to do with virtio > > :). > > > > Completely agree, new transports could use it to handle the protocol without > reimplementing things already done. > > > > + > > > +static struct workqueue_struct *vsock_loopback_workqueue; > > > +static struct vsock_loopback *the_vsock_loopback; > > > > the_vsock_loopback could be a static global variable (not a pointer) and > > vsock_loopback_workqueue could also be included in the struct. > > > > The RCU pointer is really a way to synchronize vsock_loopback_send_pkt() > > and vsock_loopback_cancel_pkt() with module exit. There is no other > > reason for using a pointer. > > > > It's cleaner to implement the synchronization once in af_vsock.c (or > > virtio_transport_common.c) instead of making each transport do it. > > Maybe try_module_get() and related APIs provide the necessary semantics > > so that core vsock code can hold the transport module while it's being > > used to send/cancel a packet. > > Right, the module cannot be unloaded until open sockets, so here the > synchronization is not needed. > > The synchronization come from virtio-vsock device that can be > hot-unplugged while sockets are still open, but that can't happen here. > > I will remove the pointers and RCU in the v2. > > Can I keep your R-b or do you prefer to watch v2 first? > > > > > > +MODULE_ALIAS_NETPROTO(PF_VSOCK); > > > > Why does this module define the alias for PF_VSOCK? Doesn't another > > module already define this alias? > > It is a way to load this module when PF_VSOCK is starting to be used. > MODULE_ALIAS_NETPROTO(PF_VSOCK) is already defined in vmci_transport > and hyperv_transport. IIUC it is used for the same reason. > > In virtio_transport we don't need it because it will be loaded when > the PCI device is discovered. > > Do you think there's a better way? > Should I include the vsock_loopback transport directly in af_vsock > without creating a new module? > That last thing I said may not be possible: I remembered that I tried, but DEPMOD found a cyclic dependency because vsock_transport use virtio_transport_common that use vsock, so if I include vsock_transport in the vsock module, DEPMOD is not happy. Do you think it's okay in this case to keep MODULE_ALIAS_NETPROTO(PF_VSOCK) or is there a better way? Thanks, Stefano
On Thu, Nov 21, 2019 at 04:25:17PM +0100, Stefano Garzarella wrote: > On Thu, Nov 21, 2019 at 10:59:48AM +0100, Stefano Garzarella wrote: > > On Thu, Nov 21, 2019 at 09:34:58AM +0000, Stefan Hajnoczi wrote: > > > On Tue, Nov 19, 2019 at 12:01:19PM +0100, Stefano Garzarella wrote: > > > > +static struct workqueue_struct *vsock_loopback_workqueue; > > > > +static struct vsock_loopback *the_vsock_loopback; > > > > > > the_vsock_loopback could be a static global variable (not a pointer) and > > > vsock_loopback_workqueue could also be included in the struct. > > > > > > The RCU pointer is really a way to synchronize vsock_loopback_send_pkt() > > > and vsock_loopback_cancel_pkt() with module exit. There is no other > > > reason for using a pointer. > > > > > > It's cleaner to implement the synchronization once in af_vsock.c (or > > > virtio_transport_common.c) instead of making each transport do it. > > > Maybe try_module_get() and related APIs provide the necessary semantics > > > so that core vsock code can hold the transport module while it's being > > > used to send/cancel a packet. > > > > Right, the module cannot be unloaded until open sockets, so here the > > synchronization is not needed. > > > > The synchronization come from virtio-vsock device that can be > > hot-unplugged while sockets are still open, but that can't happen here. > > > > I will remove the pointers and RCU in the v2. > > > > Can I keep your R-b or do you prefer to watch v2 first? I'd like to review v2. > > > > +MODULE_ALIAS_NETPROTO(PF_VSOCK); > > > > > > Why does this module define the alias for PF_VSOCK? Doesn't another > > > module already define this alias? > > > > It is a way to load this module when PF_VSOCK is starting to be used. > > MODULE_ALIAS_NETPROTO(PF_VSOCK) is already defined in vmci_transport > > and hyperv_transport. IIUC it is used for the same reason. > > > > In virtio_transport we don't need it because it will be loaded when > > the PCI device is discovered. > > > > Do you think there's a better way? > > Should I include the vsock_loopback transport directly in af_vsock > > without creating a new module? > > > > That last thing I said may not be possible: > I remembered that I tried, but DEPMOD found a cyclic dependency because > vsock_transport use virtio_transport_common that use vsock, so if I > include vsock_transport in the vsock module, DEPMOD is not happy. > > Do you think it's okay in this case to keep MODULE_ALIAS_NETPROTO(PF_VSOCK) > or is there a better way? The reason I asked is because the semantics of duplicate module aliases aren't clear to me. Do all modules with the same alias get loaded? Or just the first? Or ...? Stefan
On Fri, Nov 22, 2019 at 09:25:46AM +0000, Stefan Hajnoczi wrote: > On Thu, Nov 21, 2019 at 04:25:17PM +0100, Stefano Garzarella wrote: > > On Thu, Nov 21, 2019 at 10:59:48AM +0100, Stefano Garzarella wrote: > > > On Thu, Nov 21, 2019 at 09:34:58AM +0000, Stefan Hajnoczi wrote: > > > > On Tue, Nov 19, 2019 at 12:01:19PM +0100, Stefano Garzarella wrote: > > > > > +static struct workqueue_struct *vsock_loopback_workqueue; > > > > > +static struct vsock_loopback *the_vsock_loopback; > > > > > > > > the_vsock_loopback could be a static global variable (not a pointer) and > > > > vsock_loopback_workqueue could also be included in the struct. > > > > > > > > The RCU pointer is really a way to synchronize vsock_loopback_send_pkt() > > > > and vsock_loopback_cancel_pkt() with module exit. There is no other > > > > reason for using a pointer. > > > > > > > > It's cleaner to implement the synchronization once in af_vsock.c (or > > > > virtio_transport_common.c) instead of making each transport do it. > > > > Maybe try_module_get() and related APIs provide the necessary semantics > > > > so that core vsock code can hold the transport module while it's being > > > > used to send/cancel a packet. > > > > > > Right, the module cannot be unloaded until open sockets, so here the > > > synchronization is not needed. > > > > > > The synchronization come from virtio-vsock device that can be > > > hot-unplugged while sockets are still open, but that can't happen here. > > > > > > I will remove the pointers and RCU in the v2. > > > > > > Can I keep your R-b or do you prefer to watch v2 first? > > I'd like to review v2. > Sure! > > > > > +MODULE_ALIAS_NETPROTO(PF_VSOCK); > > > > > > > > Why does this module define the alias for PF_VSOCK? Doesn't another > > > > module already define this alias? > > > > > > It is a way to load this module when PF_VSOCK is starting to be used. > > > MODULE_ALIAS_NETPROTO(PF_VSOCK) is already defined in vmci_transport > > > and hyperv_transport. IIUC it is used for the same reason. > > > > > > In virtio_transport we don't need it because it will be loaded when > > > the PCI device is discovered. > > > > > > Do you think there's a better way? > > > Should I include the vsock_loopback transport directly in af_vsock > > > without creating a new module? > > > > > > > That last thing I said may not be possible: > > I remembered that I tried, but DEPMOD found a cyclic dependency because > > vsock_transport use virtio_transport_common that use vsock, so if I > > include vsock_transport in the vsock module, DEPMOD is not happy. > > > > Do you think it's okay in this case to keep MODULE_ALIAS_NETPROTO(PF_VSOCK) > > or is there a better way? > > The reason I asked is because the semantics of duplicate module aliases > aren't clear to me. Do all modules with the same alias get loaded? > Or just the first? Or ...? It wasn't clear to me either, but when I tried, I saw that all modules with the same alias got loaded. Stefano
diff --git a/MAINTAINERS b/MAINTAINERS index 760049454a23..c2a3dc3113ba 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -17239,6 +17239,7 @@ F: net/vmw_vsock/diag.c F: net/vmw_vsock/af_vsock_tap.c F: net/vmw_vsock/virtio_transport_common.c F: net/vmw_vsock/virtio_transport.c +F: net/vmw_vsock/vsock_loopback.c F: drivers/net/vsockmon.c F: drivers/vhost/vsock.c F: tools/testing/vsock/ diff --git a/net/vmw_vsock/Kconfig b/net/vmw_vsock/Kconfig index 8abcb815af2d..56356d2980c8 100644 --- a/net/vmw_vsock/Kconfig +++ b/net/vmw_vsock/Kconfig @@ -26,6 +26,18 @@ config VSOCKETS_DIAG Enable this module so userspace applications can query open sockets. +config VSOCKETS_LOOPBACK + tristate "Virtual Sockets loopback transport" + depends on VSOCKETS + default y + select VIRTIO_VSOCKETS_COMMON + help + This module implements a loopback transport for Virtual Sockets, + using vmw_vsock_virtio_transport_common. + + To compile this driver as a module, choose M here: the module + will be called vsock_loopback. If unsure, say N. + config VMWARE_VMCI_VSOCKETS tristate "VMware VMCI transport for Virtual Sockets" depends on VSOCKETS && VMWARE_VMCI diff --git a/net/vmw_vsock/Makefile b/net/vmw_vsock/Makefile index 7c6f9a0b67b0..6a943ec95c4a 100644 --- a/net/vmw_vsock/Makefile +++ b/net/vmw_vsock/Makefile @@ -5,6 +5,7 @@ obj-$(CONFIG_VMWARE_VMCI_VSOCKETS) += vmw_vsock_vmci_transport.o obj-$(CONFIG_VIRTIO_VSOCKETS) += vmw_vsock_virtio_transport.o obj-$(CONFIG_VIRTIO_VSOCKETS_COMMON) += vmw_vsock_virtio_transport_common.o obj-$(CONFIG_HYPERV_VSOCKETS) += hv_sock.o +obj-$(CONFIG_VSOCKETS_LOOPBACK) += vsock_loopback.o vsock-y += af_vsock.o af_vsock_tap.o vsock_addr.o diff --git a/net/vmw_vsock/vsock_loopback.c b/net/vmw_vsock/vsock_loopback.c new file mode 100644 index 000000000000..3d1c1a88305f --- /dev/null +++ b/net/vmw_vsock/vsock_loopback.c @@ -0,0 +1,217 @@ +// SPDX-License-Identifier: GPL-2.0-only +/* + * loopback transport for vsock using virtio_transport_common APIs + * + * Copyright (C) 2013-2019 Red Hat, Inc. + * Author: Asias He <asias@redhat.com> + * Stefan Hajnoczi <stefanha@redhat.com> + * Stefano Garzarella <sgarzare@redhat.com> + * + */ +#include <linux/spinlock.h> +#include <linux/module.h> +#include <linux/list.h> +#include <linux/virtio_vsock.h> + +static struct workqueue_struct *vsock_loopback_workqueue; +static struct vsock_loopback *the_vsock_loopback; + +struct vsock_loopback { + spinlock_t loopback_list_lock; /* protects loopback_list */ + struct list_head loopback_list; + struct work_struct loopback_work; +}; + +static u32 vsock_loopback_get_local_cid(void) +{ + return VMADDR_CID_LOCAL; +} + +static int vsock_loopback_send_pkt(struct virtio_vsock_pkt *pkt) +{ + struct vsock_loopback *vsock; + int len = pkt->len; + + rcu_read_lock(); + vsock = rcu_dereference(the_vsock_loopback); + if (!vsock) { + virtio_transport_free_pkt(pkt); + len = -ENODEV; + goto out_rcu; + } + + spin_lock_bh(&vsock->loopback_list_lock); + list_add_tail(&pkt->list, &vsock->loopback_list); + spin_unlock_bh(&vsock->loopback_list_lock); + + queue_work(vsock_loopback_workqueue, &vsock->loopback_work); + +out_rcu: + rcu_read_unlock(); + return len; +} + +static int vsock_loopback_cancel_pkt(struct vsock_sock *vsk) +{ + struct vsock_loopback *vsock; + struct virtio_vsock_pkt *pkt, *n; + int ret; + LIST_HEAD(freeme); + + rcu_read_lock(); + vsock = rcu_dereference(the_vsock_loopback); + if (!vsock) { + ret = -ENODEV; + goto out_rcu; + } + + spin_lock_bh(&vsock->loopback_list_lock); + list_for_each_entry_safe(pkt, n, &vsock->loopback_list, list) { + if (pkt->vsk != vsk) + continue; + list_move(&pkt->list, &freeme); + } + spin_unlock_bh(&vsock->loopback_list_lock); + + list_for_each_entry_safe(pkt, n, &freeme, list) { + list_del(&pkt->list); + virtio_transport_free_pkt(pkt); + } + + ret = 0; + +out_rcu: + rcu_read_unlock(); + return ret; +} + +static struct virtio_transport loopback_transport = { + .transport = { + .module = THIS_MODULE, + + .get_local_cid = vsock_loopback_get_local_cid, + + .init = virtio_transport_do_socket_init, + .destruct = virtio_transport_destruct, + .release = virtio_transport_release, + .connect = virtio_transport_connect, + .shutdown = virtio_transport_shutdown, + .cancel_pkt = vsock_loopback_cancel_pkt, + + .dgram_bind = virtio_transport_dgram_bind, + .dgram_dequeue = virtio_transport_dgram_dequeue, + .dgram_enqueue = virtio_transport_dgram_enqueue, + .dgram_allow = virtio_transport_dgram_allow, + + .stream_dequeue = virtio_transport_stream_dequeue, + .stream_enqueue = virtio_transport_stream_enqueue, + .stream_has_data = virtio_transport_stream_has_data, + .stream_has_space = virtio_transport_stream_has_space, + .stream_rcvhiwat = virtio_transport_stream_rcvhiwat, + .stream_is_active = virtio_transport_stream_is_active, + .stream_allow = virtio_transport_stream_allow, + + .notify_poll_in = virtio_transport_notify_poll_in, + .notify_poll_out = virtio_transport_notify_poll_out, + .notify_recv_init = virtio_transport_notify_recv_init, + .notify_recv_pre_block = virtio_transport_notify_recv_pre_block, + .notify_recv_pre_dequeue = virtio_transport_notify_recv_pre_dequeue, + .notify_recv_post_dequeue = virtio_transport_notify_recv_post_dequeue, + .notify_send_init = virtio_transport_notify_send_init, + .notify_send_pre_block = virtio_transport_notify_send_pre_block, + .notify_send_pre_enqueue = virtio_transport_notify_send_pre_enqueue, + .notify_send_post_enqueue = virtio_transport_notify_send_post_enqueue, + .notify_buffer_size = virtio_transport_notify_buffer_size, + }, + + .send_pkt = vsock_loopback_send_pkt, +}; + +static void vsock_loopback_work(struct work_struct *work) +{ + struct vsock_loopback *vsock = + container_of(work, struct vsock_loopback, loopback_work); + LIST_HEAD(pkts); + + spin_lock_bh(&vsock->loopback_list_lock); + list_splice_init(&vsock->loopback_list, &pkts); + spin_unlock_bh(&vsock->loopback_list_lock); + + while (!list_empty(&pkts)) { + struct virtio_vsock_pkt *pkt; + + pkt = list_first_entry(&pkts, struct virtio_vsock_pkt, list); + list_del_init(&pkt->list); + + virtio_transport_deliver_tap_pkt(pkt); + virtio_transport_recv_pkt(&loopback_transport, pkt); + } +} + +static int __init vsock_loopback_init(void) +{ + struct vsock_loopback *vsock = NULL; + int ret; + + vsock_loopback_workqueue = alloc_workqueue("vsock-loopback", 0, 0); + if (!vsock_loopback_workqueue) + return -ENOMEM; + + vsock = kzalloc(sizeof(*vsock), GFP_KERNEL); + if (!vsock) { + ret = -ENOMEM; + goto out_wq; + } + + spin_lock_init(&vsock->loopback_list_lock); + INIT_LIST_HEAD(&vsock->loopback_list); + INIT_WORK(&vsock->loopback_work, vsock_loopback_work); + + rcu_assign_pointer(the_vsock_loopback, vsock); + + ret = vsock_core_register(&loopback_transport.transport, + VSOCK_TRANSPORT_F_LOCAL); + if (ret) + goto out_free; + + return 0; + +out_free: + rcu_assign_pointer(the_vsock_loopback, NULL); + kfree(vsock); +out_wq: + destroy_workqueue(vsock_loopback_workqueue); + return ret; +} + +static void __exit vsock_loopback_exit(void) +{ + struct vsock_loopback *vsock = the_vsock_loopback; + struct virtio_vsock_pkt *pkt; + + vsock_core_unregister(&loopback_transport.transport); + + rcu_assign_pointer(the_vsock_loopback, NULL); + synchronize_rcu(); + + spin_lock_bh(&vsock->loopback_list_lock); + while (!list_empty(&vsock->loopback_list)) { + pkt = list_first_entry(&vsock->loopback_list, + struct virtio_vsock_pkt, list); + list_del(&pkt->list); + virtio_transport_free_pkt(pkt); + } + spin_unlock_bh(&vsock->loopback_list_lock); + + flush_work(&vsock->loopback_work); + + kfree(vsock); + destroy_workqueue(vsock_loopback_workqueue); +} + +module_init(vsock_loopback_init); +module_exit(vsock_loopback_exit); +MODULE_LICENSE("GPL v2"); +MODULE_AUTHOR("Stefano Garzarella <sgarzare@redhat.com>"); +MODULE_DESCRIPTION("loopback transport for vsock"); +MODULE_ALIAS_NETPROTO(PF_VSOCK);
This patch adds a new vsock_loopback transport to handle local communication. This transport is based on the loopback implementation of virtio_transport, so it uses the virtio_transport_common APIs to interface with the vsock core. Signed-off-by: Stefano Garzarella <sgarzare@redhat.com> --- MAINTAINERS | 1 + net/vmw_vsock/Kconfig | 12 ++ net/vmw_vsock/Makefile | 1 + net/vmw_vsock/vsock_loopback.c | 217 +++++++++++++++++++++++++++++++++ 4 files changed, 231 insertions(+) create mode 100644 net/vmw_vsock/vsock_loopback.c