search for: vmaddr_port_any

...6310794522 100644 --- a/net/vmw_vsock/hyperv_transport.c +++ b/net/vmw_vsock/hyperv_transport.c @@ -186,7 +186,8 @@ static void hvs_remote_addr_init(struct sockaddr_vm *remote, static u32 host_ephemeral_port = MIN_HOST_EPHEMERAL_PORT; struct sock *sk; - vsock_addr_init(remote, VMADDR_CID_ANY, VMADDR_PORT_ANY); + /* Remote peer is always the host */ + vsock_addr_init(remote, VMADDR_CID_HOST, VMADDR_PORT_ANY); while (1) { /* Wrap around ? */ -- 2.21.0

...cid != cid && addr->svm_cid != VMADDR_CID_ANY) return -EADDRNOTAVAIL; @@ -586,6 +588,7 @@ struct sock *__vsock_create(struct net *net, sk->sk_type = type; vsk = vsock_sk(sk); + vsk->transport = transport_single; vsock_addr_init(&vsk->local_addr, VMADDR_CID_ANY, VMADDR_PORT_ANY); vsock_addr_init(&vsk->remote_addr, VMADDR_CID_ANY, VMADDR_PORT_ANY); @@ -616,7 +619,7 @@ struct sock *__vsock_create(struct net *net, vsk->connect_timeout = VSOCK_DEFAULT_CONNECT_TIMEOUT; } - if (transport->init(vsk, psk) < 0) { + if (vsk->transport->init(vsk, psk...

...cid != cid && addr->svm_cid != VMADDR_CID_ANY) return -EADDRNOTAVAIL; @@ -586,6 +588,7 @@ struct sock *__vsock_create(struct net *net, sk->sk_type = type; vsk = vsock_sk(sk); + vsk->transport = transport_single; vsock_addr_init(&vsk->local_addr, VMADDR_CID_ANY, VMADDR_PORT_ANY); vsock_addr_init(&vsk->remote_addr, VMADDR_CID_ANY, VMADDR_PORT_ANY); @@ -616,7 +619,7 @@ struct sock *__vsock_create(struct net *net, vsk->connect_timeout = VSOCK_DEFAULT_CONNECT_TIMEOUT; } - if (transport->init(vsk, psk) < 0) { + if (vsk->transport->init(vsk, psk...

...vsock_sk(sk); - u32 cid; int retval; /* First ensure this socket isn't already bound. */ @@ -540,10 +602,9 @@ static int __vsock_bind(struct sock *sk, struct sockaddr_vm *addr) /* Now bind to the provided address or select appropriate values if * none are provided (VMADDR_CID_ANY and VMADDR_PORT_ANY). Note that * like AF_INET prevents binding to a non-local IP address (in most - * cases), we only allow binding to the local CID. + * cases), we only allow binding to a local CID. */ - cid = vsk->transport->get_local_cid(); - if (addr->svm_cid != cid && addr->svm_cid !...

...vsock_sk(sk); - u32 cid; int retval; /* First ensure this socket isn't already bound. */ @@ -540,10 +595,9 @@ static int __vsock_bind(struct sock *sk, struct sockaddr_vm *addr) /* Now bind to the provided address or select appropriate values if * none are provided (VMADDR_CID_ANY and VMADDR_PORT_ANY). Note that * like AF_INET prevents binding to a non-local IP address (in most - * cases), we only allow binding to the local CID. + * cases), we only allow binding to a local CID. */ - cid = vsk->transport->get_local_cid(); - if (addr->svm_cid != cid && addr->svm_cid !...

...truct vsock_sock *vsk, return 0; } +int vsock_bind_dgram_generic(struct vsock_sock *vsk, struct sockaddr_vm *addr) +{ + static u32 port = LAST_RESERVED_PORT + 1; + struct sockaddr_vm new_addr; + + vsock_addr_init(&new_addr, addr->svm_cid, addr->svm_port); + + if (addr->svm_port == VMADDR_PORT_ANY) { + bool found = false; + unsigned int i; + + for (i = 0; i < MAX_PORT_RETRIES; i++) { + if (port <= LAST_RESERVED_PORT) + port = LAST_RESERVED_PORT + 1; + + new_addr.svm_port = port++; + + if (!__vsock_find_unbound_socket(&new_addr)) { + found = true; + break; + } +...

On Sat, Oct 17, 2020 at 06:32:18PM +0200, Nick Wellnhofer wrote: > On Oct 17, 2020, at 12:24 , Richard W.M. Jones via xml <xml@gnome.org> wrote: > > It seems like libxml2 chose to do this for convenience rather than > > correctness. > > Yes, this is an arbitrary limit introduced to avoid integer overflow. > > > I think it should accept port numbers at least

From: Andy King <acking at vmware.com> ** Introduce VM Sockets *** In an effort to improve the out-of-the-box experience with Linux kernels for VMware users, VMware is working on readying the VM Sockets (VSOCK, formerly VMCI Sockets) (vmw_vsock) kernel module for inclusion in the Linux kernel. The purpose of this post is to acquire feedback on the vmw_vsock kernel module. Unlike previous

From: Andy King <acking at vmware.com> ** Introduce VM Sockets *** In an effort to improve the out-of-the-box experience with Linux kernels for VMware users, VMware is working on readying the VM Sockets (VSOCK, formerly VMCI Sockets) (vmw_vsock) kernel module for inclusion in the Linux kernel. The purpose of this post is to acquire feedback on the vmw_vsock kernel module. Unlike previous

* * * This series of VSOCK linux upstreaming patches include latest udpate from VMware to address Greg's and all other's code review comments. Summary of changes: - Rebase our linux kernel tree from v3.5 to v3.7. - Fix all checkpatch warnings and errors. Fix some checkpatch with -strict errors. This addresses Greg's comment: On 15 Nov 2012

* * * This series of VSOCK linux upstreaming patches include latest udpate from VMware to address Greg's and all other's code review comments. Summary of changes: - Rebase our linux kernel tree from v3.5 to v3.7. - Fix all checkpatch warnings and errors. Fix some checkpatch with -strict errors. This addresses Greg's comment: On 15 Nov 2012

* * * This series of VSOCK linux upstreaming patches include latest udpate from VMware. Summary of changes: - Sparse clean. - Checkpatch clean with one exception, a "complex macro" in which we can't add parentheses. - Remove all runtime assertions. - Fix device name, so that existing user clients work. - Fix VMCI handle lookup. * *

* * * This series of VSOCK linux upstreaming patches include latest udpate from VMware. Summary of changes: - Sparse clean. - Checkpatch clean with one exception, a "complex macro" in which we can't add parentheses. - Remove all runtime assertions. - Fix device name, so that existing user clients work. - Fix VMCI handle lookup. * *

* * * In an effort to improve the out-of-the-box experience with Linux kernels for VMware users, VMware is working on readying the Virtual Machine Communication Interface (vmw_vmci) and VMCI Sockets (VSOCK) (vmw_vsock) kernel modules for inclusion in the Linux kernel. The purpose of this post is to acquire feedback on the vmw_vsock kernel module. The vmw_vmci kernel module has been presented in

* * * In an effort to improve the out-of-the-box experience with Linux kernels for VMware users, VMware is working on readying the Virtual Machine Communication Interface (vmw_vmci) and VMCI Sockets (VSOCK) (vmw_vsock) kernel modules for inclusion in the Linux kernel. The purpose of this post is to acquire feedback on the vmw_vsock kernel module. The vmw_vmci kernel module has been presented in

Most of the patches are reviewed by Dexuan, Stefan, and Jorgen. The following patches need reviews: - [11/15] vsock: add multi-transports support - [12/15] vsock/vmci: register vmci_transport only when VMCI guest/host are active - [15/15] vhost/vsock: refuse CID assigned to the guest->host transport RFC: https://patchwork.ozlabs.org/cover/1168442/ v1:

Hi all, this series adds the multi-transports support to vsock, following this proposal: https://www.spinics.net/lists/netdev/msg575792.html With the multi-transports support, we can use vsock with nested VMs (using also different hypervisors) loading both guest->host and host->guest transports at the same time. Before this series, vmci-transport supported this behavior but only using

Hi all, this series adds the multi-transports support to vsock, following this proposal: https://www.spinics.net/lists/netdev/msg575792.html With the multi-transports support, we can use vsock with nested VMs (using also different hypervisors) loading both guest->host and host->guest transports at the same time. Before this series, vmci-transport supported this behavior but only using

This series adds the multi-transports support to vsock, following this proposal: https://www.spinics.net/lists/netdev/msg575792.html With the multi-transports support, we can use VSOCK with nested VMs (using also different hypervisors) loading both guest->host and host->guest transports at the same time. Before this series, vmci-transport supported this behavior but only using VMware

This series adds the multi-transports support to vsock, following this proposal: https://www.spinics.net/lists/netdev/msg575792.html With the multi-transports support, we can use VSOCK with nested VMs (using also different hypervisors) loading both guest->host and host->guest transports at the same time. Before this series, vmci-transport supported this behavior but only using VMware