> -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:
> 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
> 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
> 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
> 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
> 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
> 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
> 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
> 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
> 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
> 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
> 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
> 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
> 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
> 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
> 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")
>
>
> 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
> 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 ++
>
21 matches
Mail list logo