On Tue, Nov 18, 2025 at 05:17:35PM -0800, Bobby Eshleman wrote:
On Tue, Nov 18, 2025 at 07:10:28PM +0100, Stefano Garzarella wrote:
On Mon, Nov 17, 2025 at 06:00:26PM -0800, Bobby Eshleman wrote:
From: Bobby Eshleman bobbyeshleman@meta.com
[...]
diff --git a/net/vmw_vsock/vmci_transport.c b/net/vmw_vsock/vmci_transport.c index 7eccd6708d66..da7c52ad7b2a 100644 --- a/net/vmw_vsock/vmci_transport.c +++ b/net/vmw_vsock/vmci_transport.c @@ -2033,6 +2033,12 @@ static u32 vmci_transport_get_local_cid(void) return vmci_get_context_id(); }
+static bool vmci_transport_supports_local_mode(void) +{
- /* Local mode is supported only when no device is present. */
- return vmci_transport_get_local_cid() == VMCI_INVALID_ID;
IIRC vmci can be registered both as H2G and G2H, so should we filter out the H2G case?
In fact, I'm realizing now that this should probably just be:
static bool vmci_transport_supports_local_mode(void) { return false; }
... because even for H2G there is no mechanism for attaching a namespace to a VM (unlike w/ vhost_vsock device open).
Does that seem right?
tl;dr yes
vmci_transport.c has MODULE_ALIAS_NETPROTO(PF_VSOCK) for historical reasons. This means that the module is automatically loaded the first time PF_VSOCK is requested by the user if af_vsock is not loaded.
This was the case before vsock was generalized to support multiple transports and has remained so for historical reasons.
So today, we can have that module loaded, registered only for F_DGRAM but not registered for F_G2H and F_H2G, so maybe it could work for now and if the H2G is also not supporting it, maybe is the right thing to do. (with a better comment there on the reason why both G2H and H2G doesn't support it).
Sorry for the long reply, maybe just `yes` was fine, but I dumped what I thought because I feel it might be useful to you.
Thanks, Stefano