> In the unlikely event that the kmalloc call in vmci_transport_socket_init()
> fails, we end-up calling vmci_transport_destruct() with a NULL vmci_trans()
> and oopsing.
>
> This change addresses the above explicitly checking for zero vmci_trans() at
> destruction time.
>
> Reported-by: Xiumei M
>
> The old code always starts from fixed port for VMADDR_PORT_ANY.
> Sometimes when VMM crashed, there is still orphaned vsock which is waiting
> for close timer, then it could cause connection time out for new started VM if
> they are trying to connect to same port with same guest cid since the
> On Mon, Dec 10, 2018 at 11:02:35PM -0800, Lepton Wu wrote:
> > The old code always starts from fixed port for VMADDR_PORT_ANY. Sometimes
> > when VMM crashed, there is still orphaned vsock which is waiting for
> > close timer, then it could cause connection time out for new started VM
> > if th
On Sep 22, 2018, at 8:27 AM, Hangbin Liu wrote:
>
> On Fri, Sep 21, 2018 at 07:48:25AM +, Jorgen S. Hansen wrote:
>> Hi Hangbin,
>>
>> I finaly got to the bottom of this - the issue was indeed in the VMCI
>> driver. The patch is po
: Hangbin Liu
Sent: Wednesday, June 13, 2018 3:44 AM
To: Jorgen S. Hansen
Cc: Stefan Hajnoczi; netdev@vger.kernel.org; David S. Miller
Subject: Re: [PATCH net] VSOCK: check sk state before receive
On Mon, Jun 04, 2018 at 04:02:39PM +, Jorgen S. Hansen wrote:
>
> > On May 30, 2018, at
> On May 30, 2018, at 11:17 AM, Stefan Hajnoczi wrote:
>
> On Sun, May 27, 2018 at 11:29:45PM +0800, Hangbin Liu wrote:
>> Hmm...Although I won't reproduce this bug with my reproducer after
>> apply my patch. I could still get a similiar issue with syzkaller sock vnet
>> test.
>>
>> It looks t
> On Apr 17, 2018, at 8:25 AM, Stefan Hajnoczi wrote:
>
> Commit c1eef220c1760762753b602c382127bfccee226d ("vsock: always call
> vsock_init_tables()") introduced a module_init() function without a
> corresponding module_exit() function.
>
> Modules with an init function can only be removed if t
> On Jan 2, 2018, at 1:05 PM, Stefan Hajnoczi wrote:
>
> On Wed, Dec 20, 2017 at 02:48:43PM +0000, Jorgen S. Hansen wrote:
>>
>>> On Dec 13, 2017, at 3:49 PM, Stefan Hajnoczi wrote:
>>>
>>> The vsock_diag.ko module already has a test suite but the co
> On Dec 13, 2017, at 3:49 PM, Stefan Hajnoczi wrote:
>
> The vsock_diag.ko module already has a test suite but the core AF_VSOCK
> functionality has no tests. This patch series adds several test cases that
> exercise AF_VSOCK SOCK_STREAM socket semantics (send/recv, connect/accept,
> half-clos
> On Dec 12, 2017, at 4:53 PM, Stefan Hajnoczi wrote:
>
> When connect(2) fails because the peer is not listening the virtio vsock
> transport returns ECONNRESET. I believe the VMCI transport does the
> same (based on code inspection).
>
> Jorgen: Can you confirm this VMCI transport behavior?
> On Dec 5, 2017, at 11:56 AM, Stefan Hajnoczi wrote:
>
> The AF_VSOCK address family has been available since Linux 3.9 without a
> corresponding man page.
>
> This patch adds vsock.7 and describes its use along the same lines as
> existing ip.7, unix.7, and netlink.7 man pages.
>
> CC: Jorge
> On Dec 5, 2017, at 12:31 PM, Stefan Hajnoczi wrote:
>
> Since commit 3b4477d2dcf2709d0be89e2a8dced3d0f4a017f2 ("VSOCK: use TCP
> state constants for sk_state") VSOCK has used TCP_* constants for
> sk_state.
>
> Commit b4562ca7925a3bedada87a3dd072dd5bad043288 ("hv_sock: add locking
> in the op
> On Dec 1, 2017, at 2:09 PM, Stefan Hajnoczi wrote:
>
> On Thu, Nov 30, 2017 at 01:21:26PM +0000, Jorgen S. Hansen wrote:
>>> On Nov 30, 2017, at 12:21 PM, Stefan Hajnoczi wrote:
>
> Thanks for the quick review!
>
> I forgot to ask you: Is SOCK_DGRAM reliab
> On Nov 30, 2017, at 12:21 PM, Stefan Hajnoczi wrote:
>
> The AF_VSOCK address family has been available since Linux 3.9 without a
> corresponding man page.
>
> This patch adds vsock.7 and describes its use along the same lines as
> existing ip.7, unix.7, and netlink.7 man pages.
>
> CC: Jorg
> On Sep 13, 2017, at 5:19 PM, Michal Hocko wrote:
>
> On Wed 13-09-17 15:07:26, Jorgen S. Hansen wrote:
>>
>>> On Sep 12, 2017, at 11:08 AM, Michal Hocko wrote:
>>>
>>> Hi,
>>> we are seeing the following splat with Debian 3.16 stable k
> On Sep 12, 2017, at 11:08 AM, Michal Hocko wrote:
>
> Hi,
> we are seeing the following splat with Debian 3.16 stable kernel
>
> BUG: scheduling while atomic: MATLAB/26771/0x0100
> Modules linked in: veeamsnap(O) hmac cbc cts nfsv4 dns_resolver
> rpcsec_gss_krb5 nfsd auth_rpcgss oid_regi
> On Sep 12, 2017, at 6:34 PM, Stefan Hajnoczi wrote:
>
> This patch fixes the following compiler errors when userspace
> applications use the vm_sockets.h header:
>
> include/uapi/linux/vm_sockets.h:148:32: error: invalid application of
> ‘sizeof’ to incomplete type ‘struct sockaddr’
>un
> On Aug 31, 2017, at 1:54 PM, Stefan Hajnoczi wrote:
>
> On Tue, Aug 29, 2017 at 03:37:07PM +0000, Jorgen S. Hansen wrote:
>>> On Aug 29, 2017, at 4:36 AM, Dexuan Cui wrote:
>> If we allow multiple host side transports, virtio host side support and
>> vmci should
> On Aug 29, 2017, at 4:36 AM, Dexuan Cui wrote:
>
>> From: Dexuan Cui
>> Sent: Tuesday, August 22, 2017 21:21
>>> ...
>>> ...
>>> The only problem here would be the potential for a guest and a host app
>> to
>>> have a conflict wrt port numbers, even though they would be able to
>>> operate fin
> On Aug 22, 2017, at 11:54 AM, Stefan Hajnoczi wrote:
>
> On Fri, Aug 18, 2017 at 11:07:37PM +, Dexuan Cui wrote:
>>> Not all features need to be supported. For example, VMCI supports
>>> SOCK_DGRAM while Hyper-V and virtio do not. But features that are
>>> available should behave identic
> On Aug 17, 2017, at 3:55 PM, Stefan Hajnoczi wrote:
>
> On Thu, Aug 17, 2017 at 08:00:29AM +, Dexuan Cui wrote:
>>
>> Without the patch, vmw_vsock_vmci_transport.ko can automatically load
>> when an application creates an AF_VSOCK socket.
>>
>> This is the expected good behavior on VMwar
> On Aug 16, 2017, at 12:15 AM, Dexuan Cui wrote:
>
>
> With the current code, when vsock_dequeue_accept() is removing a sock
> from the list, nothing prevents vsock_enqueue_accept() from adding a new
> sock into the list concurrently. We should add a lock to protect the list.
>
For the VMCI
> On Aug 16, 2017, at 12:13 AM, Dexuan Cui wrote:
>
>
> Without the patch, vmw_vsock_vmci_transport.ko and vmw_vmci.ko can
> automatically load when an application creates an AF_VSOCK socket.
>
> This is the expected good behavior on VMware hypervisor, but as we
> are going to add hv_sock.ko (
Hi Stefan,
> On Aug 3, 2017, at 12:41 PM, Stefan Hajnoczi wrote:
>
> Hi Jorgen,
> There are 3 sockopts defined in include/uapi/linux/vm_sockets.h that are
> currently not implemented in net/vmw_vsock/af_vsock.c:
>
> * SO_VM_SOCKETS_PEER_HOST_VM_ID
> * SO_VM_SOCKETS_TRUSTED
> * SO_VM_SOCKETS_NON
> On Apr 21, 2017, at 11:10 AM, Stefan Hajnoczi wrote:
>
> From: Gerard Garcia
>
> Add tap functions that can be used by the vsock transports to
> deliver packets to vsockmon virtual network devices.
>
> Signed-off-by: Gerard Garcia
> Signed-off-by: Stefan Hajnoczi
> ---
> v5:
> * Change vs
> On Apr 21, 2017, at 11:10 AM, Stefan Hajnoczi wrote:
>
> From: Gerard Garcia
>
> The virtio drivers deal with struct virtio_vsock_pkt. Add
> virtio_transport_deliver_tap_pkt(pkt) for handing packets to the
> vsockmon device.
>
> We call virtio_transport_deliver_tap_pkt(pkt) from
> net/vmw_
>
> +/* Packet capture */
> +void virtio_transport_deliver_tap_pkt(struct virtio_vsock_pkt *pkt)
> +{
> + struct sk_buff *skb;
> + struct af_vsockmon_hdr *hdr;
> + unsigned char *t_hdr, *payload;
> +
> + skb = alloc_skb(sizeof(*hdr) + sizeof(pkt->hdr) + pkt->len,
> +
> On Apr 13, 2017, at 6:18 PM, Stefan Hajnoczi wrote:
>
> +
> +static void __vsock_deliver_tap(struct sk_buff *skb)
> +{
> + int ret;
> + struct vsock_tap *tmp;
> +
> + list_for_each_entry_rcu(tmp, &vsock_tap_all, list) {
> + ret = __vsock_deliver_tap_skb(skb, tmp->dev);
> On Mar 29, 2017, at 5:33 PM, Colin King wrote:
>
> From: Colin Ian King
>
> Rather than assign the positive errno values to ret and then
> checking if it is positive and flip the sign, just return the
> errno value.
>
> Detected by CoverityScan, CID#986649 ("Logically Dead Code")
>
> Signe
Hello,
We’d like the following commit to be backported to 4.4 stable. The commit fixes
a bug that was introduced in 4.3 and fixed in 4.6. The bug may cause wrongful
termination of vSocket connections, if there is more than one active vSocket
connection in a given VM. This affects customers runn
> On Jan 9, 2017, at 11:06 AM, Stefan Hajnoczi wrote:
>
> On Fri, Jan 06, 2017 at 10:22:56AM +0800, Peng Tao wrote:
>> On Tue, Dec 13, 2016 at 5:50 PM, Stefan Hajnoczi wrote:
>>> On Mon, Dec 12, 2016 at 08:21:05PM +0800, Peng Tao wrote:
Currently, if a connect call fails on a signal or tim
> On Dec 12, 2016, at 1:21 PM, Peng Tao wrote:
>
> To allow canceling all packets of a connection.
>
> Reviewed-by: Stefan Hajnoczi
> Signed-off-by: Peng Tao
> ---
> drivers/vhost/vsock.c | 41 +
> include/net/af_vsock.h | 3 +++
> 2 files changed, 44 i
> On Dec 8, 2016, at 6:12 PM, Peng Tao wrote:
>
> Otherwise we'll leave the packets queued until releasing vsock device.
> E.g., if guest is slow to start up, resulting ETIMEDOUT on connect, guest
> will get the connect requests from failed host sockets.
>
> Reviewed-by: Stefan Hajnoczi
> Sign
> On Dec 8, 2016, at 6:12 PM, Peng Tao wrote:
>
> --- a/include/net/af_vsock.h
> +++ b/include/net/af_vsock.h
> @@ -100,6 +100,9 @@ struct vsock_transport {
> void (*destruct)(struct vsock_sock *);
> void (*release)(struct vsock_sock *);
>
> + /* Cancel packets belonging the sam
Hi Stefan,
> On Nov 23, 2016, at 3:55 PM, Stefan Hajnoczi wrote:
>
> Hi Jorgen,
> There are two use cases where network namespace support in AF_VSOCK
> could be useful:
>
> 1. Claudio Imbrenda pointed out that a machine cannot act as both host
> and guest at the same time. This is necessary
Hi Stefan,
That should make it on par with the VMCI transport.
Thanks,
Jørgen
From: Stefan Hajnoczi
Sent: Thursday, November 17, 2016 4:49 PM
To: netdev@vger.kernel.org
Cc: cav...@redhat.com; Claudio Imbrenda; Jorgen S. Hansen; David S . Miller;
Stefan
__
From: Stefan Hajnoczi
Sent: Thursday, November 10, 2016 3:43 PM
To: Jorgen S. Hansen
Cc: cav...@redhat.com; netdev@vger.kernel.org
Subject: AF_VSOCK loopback
Hi Jorgen,
Cathy Avery found that the AF_VSOCK VMCI transport does loopback inside
the guest (but not on the host?). The v
Hello,
It would be great if the following commit could be backported to 4.4 stable.
The commit fixes a bug that was introduced in 4.3 and fixed in 4.6. The bug may
cause wrongful termination of vSocket connections, if there is more than one
active vSocket connection in a given VM. This affects
> On Jun 23, 2016, at 5:28 PM, Stefan Hajnoczi wrote:
>
> There are several places where the listener and pending or accept queue
> child sockets are accessed at the same time. Lockdep is unhappy that
> two locks from the same class are held.
>
> Tell lockdep that it is safe and document the l
Hi Stefan,
Good catch. Thanks for pointing this out. I'll take care of fixing and testing
this.
Thanks,
Jørgen
From: Stefan Hajnoczi
Sent: Thursday, June 23, 2016 5:40 PM
To: Jorgen S. Hansen
Cc: netdev@vger.kernel.org
Subject: vmw_
On 6/10/16, 5:44 PM, "Stefan Hajnoczi" wrote:
>On Thu, Jun 09, 2016 at 05:02:47PM +0200, Gerard Garcia wrote:
>> On 06/01/2016 11:07 PM, Stefan Hajnoczi wrote:
>> > On Sat, May 28, 2016 at 06:29:05PM +0200, ggar...@abra.uab.cat wrote:
>> > > diff --git a/net/vmw_vsock/af_vsock.c b/net/vmw_vsock
41 matches
Mail list logo
