search for: vsock_loopback_cancel_pkt

...ack *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 p...

...ack *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 p...

...t *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...

...t *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...

...> > > > > 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...

...gt; +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 sema...

v2: - style fixes [Dave] - removed RCU sync and changed 'the_vsock_loopback' in a global static variable [Stefan] - use G2H transport when local transport is not loaded and remote cid is VMADDR_CID_LOCAL [Stefan] - rebased on net-next v1: https://patchwork.kernel.org/cover/11251735/ This series introduces a new transport (vsock_loopback) to handle local communication. This