Linux-HyperV Archive on lore.kernel.org
 help / color / Atom feed
From: Stefan Hajnoczi <stefanha@gmail.com>
To: Stefano Garzarella <sgarzare@redhat.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: Wed, 9 Oct 2019 14:11:23 +0100
Message-ID: <20191009131123.GK5747@stefanha-x1.localdomain> (raw)
In-Reply-To: <20190927112703.17745-11-sgarzare@redhat.com>

[-- Attachment #1: Type: text/plain, Size: 2463 bytes --]

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.  There would need to be something
equivalent for the host side too.

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.

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

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

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

  reply index

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-09-27 11:26 [RFC PATCH 00/13] " 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 [this message]
2019-10-10 12:55     ` Stefano Garzarella
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 publically 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=20191009131123.GK5747@stefanha-x1.localdomain \
    --to=stefanha@gmail.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=sgarzare@redhat.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

Linux-HyperV Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-hyperv/0 linux-hyperv/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-hyperv linux-hyperv/ https://lore.kernel.org/linux-hyperv \
		linux-hyperv@vger.kernel.org
	public-inbox-index linux-hyperv

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-hyperv


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git