From: Stefano Garzarella <sgarzare@redhat.com>
To: Stefan Hajnoczi <stefanha@gmail.com>
Cc: netdev@vger.kernel.org, Sasha Levin <sashal@kernel.org>,
linux-hyperv@vger.kernel.org,
Stephen Hemminger <sthemmin@microsoft.com>,
kvm@vger.kernel.org, "Michael S. Tsirkin" <mst@redhat.com>,
Dexuan Cui <decui@microsoft.com>,
Haiyang Zhang <haiyangz@microsoft.com>,
linux-kernel@vger.kernel.org,
virtualization@lists.linux-foundation.org,
Stefan Hajnoczi <stefanha@redhat.com>,
"David S. Miller" <davem@davemloft.net>,
Jorgen Hansen <jhansen@vmware.com>
Subject: Re: [RFC PATCH 10/13] vsock: add multi-transports support
Date: Thu, 10 Oct 2019 14:55:21 +0200 [thread overview]
Message-ID: <20191010125521.mf7elqjpwhwjhwpo@steredhat> (raw)
In-Reply-To: <20191009131123.GK5747@stefanha-x1.localdomain>
On Wed, Oct 09, 2019 at 02:11:23PM +0100, Stefan Hajnoczi wrote:
> On Fri, Sep 27, 2019 at 01:27:00PM +0200, Stefano Garzarella wrote:
> > RFC:
> > - I'd like to move MODULE_ALIAS_NETPROTO(PF_VSOCK) to af_vsock.c.
> > @Jorgen could this break the VMware products?
>
> What will cause the vmw_vsock_vmci_transport.ko module to be loaded
> after you remove MODULE_ALIAS_NETPROTO(PF_VSOCK)? Perhaps
> drivers/misc/vmw_vmci/vmci_guest.c:vmci_guest_probe_device() could do
> something when the guest driver loads.
Good idea, maybe we can call some function provided by vmci_transport
to register it as a guest (I'll remove the type from the transport
and I add it as a parameter of vsock_core_register())
> There would need to be something
> equivalent for the host side too.
Maybe in the vmci_host_do_init_context().
>
> This will solve another issue too. Today the VMCI transport can be
> loaded if an application creates an AF_VSOCK socket during early boot
> before the virtio transport has been probed. This happens because the
> VMCI transport uses MODULE_ALIAS_NETPROTO(PF_VSOCK) *and* it does not
> probe whether this system is actually a VMware guest.
>
> If we instead load the core af_vsock.ko module and transports are only
> loaded based on hardware feature probing (e.g. the presence of VMware
> guest mode, a virtio PCI adapter, etc) then transports will be
> well-behaved.
Yes, I completely agree with you. I'll try to follow your suggestion,
>
> > - DGRAM sockets are handled as before, I don't know if make sense work
> > on it now, or when another transport will support DGRAM. The big
> > issues here is that we cannot link 1-1 a socket to transport as
> > for stream sockets since DGRAM is not connection-oriented.
>
> Let's ignore DGRAM for now since only VMCI supports it and we therefore
> do not require multi-transpor) support.
Okay :)
>
> > diff --git a/include/net/af_vsock.h b/include/net/af_vsock.h
> > index 86f8f463e01a..2a081d19e20d 100644
> > --- a/include/net/af_vsock.h
> > +++ b/include/net/af_vsock.h
> > @@ -94,7 +94,13 @@ struct vsock_transport_send_notify_data {
> > u64 data2; /* Transport-defined. */
> > };
> >
> > +#define VSOCK_TRANSPORT_F_H2G 0x00000001
> > +#define VSOCK_TRANSPORT_F_G2H 0x00000002
> > +#define VSOCK_TRANSPORT_F_DGRAM 0x00000004
>
> Documentation comments, please.
I'll fix!
>
> > +void vsock_core_unregister(const struct vsock_transport *t)
> > +{
> > + mutex_lock(&vsock_register_mutex);
> > +
> > + /* RFC-TODO: maybe we should check if there are open sockets
> > + * assigned to that transport and avoid the unregistration
> > + */
>
> If unregister() is only called from module_exit() functions then holding
> a reference to the transport module would be enough to prevent this
> case. The transport could only be removed once all sockets have been
> destroyed (and dropped their transport module reference).
Yes. I did this in
"[RFC PATCH 12/13] vsock: prevent transport modules unloading".
Maybe I can merge it in this patch...
Thanks,
Stefano
next prev parent reply other threads:[~2019-10-10 12:55 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-09-27 11:26 [RFC PATCH 00/13] vsock: add multi-transports support Stefano Garzarella
2019-09-27 11:26 ` [RFC PATCH 01/13] vsock/vmci: remove unused VSOCK_DEFAULT_CONNECT_TIMEOUT Stefano Garzarella
2019-10-09 11:41 ` Stefan Hajnoczi
2019-09-27 11:26 ` [RFC PATCH 02/13] vsock: remove vm_sockets_get_local_cid() Stefano Garzarella
2019-10-09 11:42 ` Stefan Hajnoczi
2019-09-27 11:26 ` [RFC PATCH 03/13] vsock: remove include/linux/vm_sockets.h file Stefano Garzarella
2019-10-09 11:43 ` Stefan Hajnoczi
2019-09-27 11:26 ` [RFC PATCH 04/13] vsock: add 'transport' member in the struct vsock_sock Stefano Garzarella
2019-10-09 11:46 ` Stefan Hajnoczi
2019-09-27 11:26 ` [RFC PATCH 05/13] vsock/virtio: add transport parameter to the virtio_transport_reset_no_sock() Stefano Garzarella
2019-10-09 11:52 ` Stefan Hajnoczi
2019-09-27 11:26 ` [RFC PATCH 06/13] vsock: add 'struct vsock_sock *' param to vsock_core_get_transport() Stefano Garzarella
2019-10-09 11:54 ` Stefan Hajnoczi
2019-10-10 8:50 ` Stefano Garzarella
2019-09-27 11:26 ` [RFC PATCH 07/13] vsock: handle buffer_size sockopts in the core Stefano Garzarella
2019-10-03 20:11 ` Dexuan Cui
2019-10-09 12:30 ` Stefan Hajnoczi
2019-10-10 9:32 ` Stefano Garzarella
2019-10-11 8:27 ` Stefan Hajnoczi
2019-10-11 8:51 ` Stefano Garzarella
2019-09-27 11:26 ` [RFC PATCH 08/13] vsock: move vsock_insert_unbound() in the vsock_create() Stefano Garzarella
2019-10-03 20:17 ` Dexuan Cui
2019-10-09 12:34 ` Stefan Hajnoczi
2019-10-10 9:52 ` Stefano Garzarella
2019-09-27 11:26 ` [RFC PATCH 09/13] hv_sock: set VMADDR_CID_HOST in the hvs_remote_addr_init() Stefano Garzarella
2019-10-03 19:36 ` Dexuan Cui
2019-10-09 12:35 ` Stefan Hajnoczi
2019-09-27 11:27 ` [RFC PATCH 10/13] vsock: add multi-transports support Stefano Garzarella
2019-10-09 13:11 ` Stefan Hajnoczi
2019-10-10 12:55 ` Stefano Garzarella [this message]
2019-09-27 11:27 ` [RFC PATCH 11/13] vsock: add 'transport_hg' to handle g2h\h2g transports Stefano Garzarella
2019-10-09 9:44 ` Stefano Garzarella
2019-10-09 13:16 ` Stefan Hajnoczi
2019-10-10 13:04 ` Stefano Garzarella
2019-09-27 11:27 ` [RFC PATCH 12/13] vsock: prevent transport modules unloading Stefano Garzarella
2019-10-09 13:28 ` Stefan Hajnoczi
2019-09-27 11:27 ` [RFC PATCH 13/13] vsock: fix bind() behaviour taking care of CID Stefano Garzarella
2019-10-09 13:29 ` Stefan Hajnoczi
2019-10-04 0:04 ` [RFC PATCH 00/13] vsock: add multi-transports support Dexuan Cui
2019-10-04 9:16 ` Stefano Garzarella
2019-10-09 13:29 ` Stefan Hajnoczi
2019-10-10 8:45 ` Stefano Garzarella
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20191010125521.mf7elqjpwhwjhwpo@steredhat \
--to=sgarzare@redhat.com \
--cc=davem@davemloft.net \
--cc=decui@microsoft.com \
--cc=haiyangz@microsoft.com \
--cc=jhansen@vmware.com \
--cc=kvm@vger.kernel.org \
--cc=linux-hyperv@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mst@redhat.com \
--cc=netdev@vger.kernel.org \
--cc=sashal@kernel.org \
--cc=stefanha@gmail.com \
--cc=stefanha@redhat.com \
--cc=sthemmin@microsoft.com \
--cc=virtualization@lists.linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).