RE: [PATCH] VMCI: Verify PPNs before sending to device

2019-01-14 Thread Jorgen S. Hansen
> -Original Message- > From: Jorgen Hansen [mailto:jhan...@vmware.com] > Sent: Friday, January 11, 2019 8:58 AM > To: linux-kernel@vger.kernel.org; virtualizat...@lists.linux-foundation.org > Cc: gre...@linuxfoundation.org; Pv-drivers ; > Jorgen S. Hansen > Subject:

Re: scheduling while atomic from vmci_transport_recv_stream_cb in 3.16 kernels

2017-09-13 Thread Jorgen S. Hansen
> On Sep 13, 2017, at 5:19 PM, Michal Hocko <mho...@kernel.org> wrote: > > On Wed 13-09-17 15:07:26, Jorgen S. Hansen wrote: >> >>> On Sep 12, 2017, at 11:08 AM, Michal Hocko <mho...@kernel.org> wrote: >>> >>> Hi, >>> w

Re: scheduling while atomic from vmci_transport_recv_stream_cb in 3.16 kernels

2017-09-13 Thread Jorgen S. Hansen
> 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

Re: scheduling while atomic from vmci_transport_recv_stream_cb in 3.16 kernels

2017-09-13 Thread Jorgen S. Hansen
> 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

Re: scheduling while atomic from vmci_transport_recv_stream_cb in 3.16 kernels

2017-09-13 Thread Jorgen S. Hansen
> 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

Re: [PATCH] vsock: only load vmci transport on VMware hypervisor by default

2017-09-06 Thread Jorgen S. Hansen
> On Aug 31, 2017, at 1:54 PM, Stefan Hajnoczi <stefa...@redhat.com> 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 <de...@microsoft.com> wrote: >> If we allow multiple host side

Re: [PATCH] vsock: only load vmci transport on VMware hypervisor by default

2017-09-06 Thread Jorgen S. Hansen
> 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

Re: [PATCH] vsock: only load vmci transport on VMware hypervisor by default

2017-08-29 Thread Jorgen S. Hansen
> 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

Re: [PATCH] vsock: only load vmci transport on VMware hypervisor by default

2017-08-29 Thread Jorgen S. Hansen
> 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

Re: [PATCH] vsock: only load vmci transport on VMware hypervisor by default

2017-08-22 Thread Jorgen S. Hansen
> 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

Re: [PATCH] vsock: only load vmci transport on VMware hypervisor by default

2017-08-22 Thread Jorgen S. Hansen
> 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

Re: [PATCH] vsock: only load vmci transport on VMware hypervisor by default

2017-08-17 Thread Jorgen S. Hansen
> 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

Re: [PATCH] vsock: only load vmci transport on VMware hypervisor by default

2017-08-17 Thread Jorgen S. Hansen
> 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

Re: [PATCH net-next 2/3] vsock: fix vsock_dequeue/enqueue_accept race

2017-08-17 Thread Jorgen S. Hansen
> 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

Re: [PATCH net-next 2/3] vsock: fix vsock_dequeue/enqueue_accept race

2017-08-17 Thread Jorgen S. Hansen
> 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

Re: [PATCH net-next 1/3] VMCI: only load on VMware hypervisor

2017-08-16 Thread Jorgen S. Hansen
> 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

Re: [PATCH net-next 1/3] VMCI: only load on VMware hypervisor

2017-08-16 Thread Jorgen S. Hansen
> 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

Re: [PATCH][V2] VSOCK: remove unnecessary ternary operator on return value

2017-03-30 Thread Jorgen S. Hansen
> 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

Re: [PATCH][V2] VSOCK: remove unnecessary ternary operator on return value

2017-03-30 Thread Jorgen S. Hansen
> 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") > >

Re: [PATCH] vmw_vmci: switch to pci_irq_alloc_vectors

2017-02-03 Thread Jorgen S. Hansen
> On Feb 1, 2017, at 3:42 PM, Christoph Hellwig wrote: > > Cleans up the IRQ management code a lot, including removing a lot of > state from the per-device structure. > > Signed-off-by: Christoph Hellwig > --- > drivers/misc/vmw_vmci/vmci_guest.c | 75

Re: [PATCH] vmw_vmci: switch to pci_irq_alloc_vectors

2017-02-03 Thread Jorgen S. Hansen
> On Feb 1, 2017, at 3:42 PM, Christoph Hellwig wrote: > > Cleans up the IRQ management code a lot, including removing a lot of > state from the per-device structure. > > Signed-off-by: Christoph Hellwig > --- > drivers/misc/vmw_vmci/vmci_guest.c | 75 ++ >