RE: PROBLEM: 4.15.0-rc3 APIC causes lockups on Core 2 Duo laptop

> From: Alexandru Chirvasitu [mailto:achirva...@gmail.com] > Sent: Friday, December 22, 2017 14:29 > > The output of that precise command run just now on a freshly-compiled > copy of that commit is attached. > > On Fri, Dec 22, 2017 at 09:31:28PM +, Dexuan Cui wrote:

RE: PROBLEM: 4.15.0-rc3 APIC causes lockups on Core 2 Duo laptop

> From: Alexandru Chirvasitu [mailto:achirva...@gmail.com] > Sent: Friday, December 22, 2017 06:21 > > In the absence of logs, the best I can do at the moment is attach a > picture of the screen I am presented with on the apic=debug boot > attempt. > Alex The panic happens in

RE: PROBLEM: 4.15.0-rc3 APIC causes lockups on Core 2 Duo laptop

> From: Alexandru Chirvasitu [mailto:achirva...@gmail.com] > Sent: Friday, December 22, 2017 06:21 > > In the absence of logs, the best I can do at the moment is attach a > picture of the screen I am presented with on the apic=debug boot > attempt. > Alex The panic happens in

RE: [PATCH 1/2] vmbus: unregister device_obj->channels_kset

> From: Greg KH [mailto:gre...@linuxfoundation.org] > Sent: Monday, December 11, 2017 12:59 PM > To: Dexuan Cui <de...@microsoft.com> > Cc: Stephen Hemminger <step...@networkplumber.org>; o...@aepfle.de; > Stephen Hemminger <sthem...@microsoft.com>; ja

RE: [PATCH 1/2] vmbus: unregister device_obj->channels_kset

> From: Greg KH [mailto:gre...@linuxfoundation.org] > Sent: Monday, December 11, 2017 12:59 PM > To: Dexuan Cui > Cc: Stephen Hemminger ; o...@aepfle.de; > Stephen Hemminger ; jasow...@redhat.com; > linux-kernel@vger.kernel.org; sta...@vger.kernel.org; a...@canonical

RE: [PATCH 1/2] vmbus: unregister device_obj->channels_kset

; On Tue, 28 Nov 2017 16:56:05 +0100 > Greg KH <gre...@linuxfoundation.org> wrote: > > > On Tue, Nov 14, 2017 at 06:53:32AM -0700, k...@exchange.microsoft.com > wrote: > > > From: Dexuan Cui <de...@microsoft.com> > > > > > > Fixes: c2e5df616e1a (&

RE: [PATCH 1/2] vmbus: unregister device_obj->channels_kset

t; > On Tue, Nov 14, 2017 at 06:53:32AM -0700, k...@exchange.microsoft.com > wrote: > > > From: Dexuan Cui > > > > > > Fixes: c2e5df616e1a ("vmbus: add per-channel sysfs info") > > > > > > Without the patch, a device can't be

RE: [PATCH 0/4] hv_balloon: fixes for num_pages_onlined accounting and misc improvements

> -Original Message- > From: Haiyang Zhang > Sent: Wednesday, November 29, 2017 16:55 > > -Original Message- > > From: Vitaly Kuznetsov [mailto:vkuzn...@redhat.com] > > Vitaly Kuznetsov writes: > > > > > While doing routing code review I noticed that commit

RE: [PATCH 0/4] hv_balloon: fixes for num_pages_onlined accounting and misc improvements

> -Original Message- > From: Haiyang Zhang > Sent: Wednesday, November 29, 2017 16:55 > > -Original Message- > > From: Vitaly Kuznetsov [mailto:vkuzn...@redhat.com] > > Vitaly Kuznetsov writes: > > > > > While doing routing code review I noticed that commit 6df8d9aaf3af > > >

[PATCH] vmbus: unregister device_obj->channels_kset

Fixes: c2e5df616e1a ("vmbus: add per-channel sysfs info") Without the patch, a device can't be thoroughly destroyed, because vmbus_device_register() -> kset_create_and_add() still holds a reference to the hv_device's device.kobj. Signed-off-by: Dexuan Cui <de...@microsoft.

[PATCH] vmbus: unregister device_obj->channels_kset

Fixes: c2e5df616e1a ("vmbus: add per-channel sysfs info") Without the patch, a device can't be thoroughly destroyed, because vmbus_device_register() -> kset_create_and_add() still holds a reference to the hv_device's device.kobj. Signed-off-by: Dexuan Cui Cc: Stephen Hemmin

RE: [PATCH] PCI: hv: use effective affinity mask

> From: Bjorn Helgaas [mailto:helg...@kernel.org] > Sent: Tuesday, November 7, 2017 5:08 PM > On Wed, Nov 01, 2017 at 08:30:53PM +0000, Dexuan Cui wrote: > > > > Please consider this for v4.14, if it's not too late. > > What would be the rationale for putting it

RE: [PATCH] PCI: hv: use effective affinity mask

> From: Bjorn Helgaas [mailto:helg...@kernel.org] > Sent: Tuesday, November 7, 2017 5:08 PM > On Wed, Nov 01, 2017 at 08:30:53PM +0000, Dexuan Cui wrote: > > > > Please consider this for v4.14, if it's not too late. > > What would be the rationale for putting it

[PATCH] PCI: hv: use effective affinity mask

a 32-vCPU VM, one of the VFs may fail to receive interrupts. Signed-off-by: Dexuan Cui <de...@microsoft.com> Cc: Jake Oshins <ja...@microsoft.com> Cc: Jork Loeser <jloe...@microsoft.com> Cc: Stephen Hemminger <sthem...@microsoft.com> Cc: K. Y. Srinivasan <k...@microsoft.com&

[PATCH] PCI: hv: use effective affinity mask

a 32-vCPU VM, one of the VFs may fail to receive interrupts. Signed-off-by: Dexuan Cui Cc: Jake Oshins Cc: Jork Loeser Cc: Stephen Hemminger Cc: K. Y. Srinivasan --- Please consider this for v4.14, if it's not too late. drivers/pci/host/pci-hyperv.c | 8 +--- 1 file changed, 5 insertions(+), 3

[PATCH net] hv_sock: add locking in the open/close/release code paths

ace, and next when the userspace closes the connection quickly, hvs_release() may not see the connection in the connected queue; finally hvs_open_connection() inserts the connection into the queue, but we won't be able to purge the connection for ever. Signed-off-by: Dexuan Cui <de...@microsoft.com>

[PATCH net] hv_sock: add locking in the open/close/release code paths

ace, and next when the userspace closes the connection quickly, hvs_release() may not see the connection in the connected queue; finally hvs_open_connection() inserts the connection into the queue, but we won't be able to purge the connection for ever. Signed-off-by: Dexuan Cui Cc: K. Y. Srinivasan

RE: [patch 3/3] x86/vector/msi: Select CONFIG_GENERIC_IRQ_RESERVATION_MODE

> From: Thomas Gleixner [mailto:t...@linutronix.de] > Sent: Tuesday, October 17, 2017 12:55 AM > --- a/arch/x86/Kconfig > +++ b/arch/x86/Kconfig > @@ -95,7 +95,7 @@ config X86 > select GENERIC_IRQ_MATRIX_ALLOCATOR if X86_LOCAL_APIC > select GENERIC_IRQ_MIGRATIONif SMP >

RE: [patch 3/3] x86/vector/msi: Select CONFIG_GENERIC_IRQ_RESERVATION_MODE

> From: Thomas Gleixner [mailto:t...@linutronix.de] > Sent: Tuesday, October 17, 2017 12:55 AM > --- a/arch/x86/Kconfig > +++ b/arch/x86/Kconfig > @@ -95,7 +95,7 @@ config X86 > select GENERIC_IRQ_MATRIX_ALLOCATOR if X86_LOCAL_APIC > select GENERIC_IRQ_MIGRATIONif SMP >

[PATCH] PCI: hv: fix "spurious APIC interrupt" due to new vector reservation mode

st add this new flag MSI_FLAG_MUST_REACTIVATE when calling pci_msi_create_irq_domain() on x86, otherwise Hyper-V PCIe pass-through can't work, and we get: "spurious APIC interrupt through vector ff on CPU#0, should never happen", this is because no valid MSI/MSI-X vector is allocated. Signed-off-by: D

[PATCH] PCI: hv: fix "spurious APIC interrupt" due to new vector reservation mode

st add this new flag MSI_FLAG_MUST_REACTIVATE when calling pci_msi_create_irq_domain() on x86, otherwise Hyper-V PCIe pass-through can't work, and we get: "spurious APIC interrupt through vector ff on CPU#0, should never happen", this is because no valid MSI/MSI-X vector is allocated. Signed-off-by: D

[PATCH] vmbus: hvsock: add proper sync for vmbus_hvsock_device_unregister()

Without the patch, vmbus_hvsock_device_unregister() can destroy the device prematurely when close() is called, and can cause NULl dereferencing or potential data loss (the last portion of the data stream may be dropped prematurely). Signed-off-by: Dexuan Cui <de...@microsoft.com> Cc

[PATCH] vmbus: hvsock: add proper sync for vmbus_hvsock_device_unregister()

Without the patch, vmbus_hvsock_device_unregister() can destroy the device prematurely when close() is called, and can cause NULl dereferencing or potential data loss (the last portion of the data stream may be dropped prematurely). Signed-off-by: Dexuan Cui Cc: K. Y. Srinivasan Cc: Haiyang

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

> From: Jorgen S. Hansen [mailto:jhan...@vmware.com] > Sent: Wednesday, September 6, 2017 7:11 AM >> ... > > I'm currently working on NFS over AF_VSOCK and sock_diag support (for > > ss(8) and netstat-like tools). > > > > Multi-transport support is lower priority for me at the moment. I'm > >

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

> From: Jorgen S. Hansen [mailto:jhan...@vmware.com] > Sent: Wednesday, September 6, 2017 7:11 AM >> ... > > I'm currently working on NFS over AF_VSOCK and sock_diag support (for > > ss(8) and netstat-like tools). > > > > Multi-transport support is lower priority for me at the moment. I'm > >

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

> From: Stefan Hajnoczi [mailto:stefa...@redhat.com] > Sent: Thursday, August 31, 2017 4:55 AM > ... > On Tue, Aug 29, 2017 at 03:37:07PM +, Jorgen S. Hansen wrote: > > > On Aug 29, 2017, at 4:36 AM, Dexuan Cui <de...@microsoft.com> wrote: > > If we allow mult

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

> From: Stefan Hajnoczi [mailto:stefa...@redhat.com] > Sent: Thursday, August 31, 2017 4:55 AM > ... > On Tue, Aug 29, 2017 at 03:37:07PM +, Jorgen S. Hansen wrote: > > > On Aug 29, 2017, at 4:36 AM, Dexuan Cui wrote: > > If we allow multiple host side transport

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

> 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 fine, if re

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

> 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 fine, if re

RE: [PATCH v3 net-next 1/1] hv_sock: implements Hyper-V transport for Virtual Sockets (AF_VSOCK)

> From: David Miller [mailto:da...@davemloft.net] > Sent: Monday, August 28, 2017 15:39 > From: Dexuan Cui <de...@microsoft.com> > Date: Sat, 26 Aug 2017 04:52:43 + > > > > > Hyper-V Sockets (hv_sock) supplies a byte-stream based communication > > m

RE: [PATCH v3 net-next 1/1] hv_sock: implements Hyper-V transport for Virtual Sockets (AF_VSOCK)

> From: David Miller [mailto:da...@davemloft.net] > Sent: Monday, August 28, 2017 15:39 > From: Dexuan Cui > Date: Sat, 26 Aug 2017 04:52:43 + > > > > > Hyper-V Sockets (hv_sock) supplies a byte-stream based communication > > mechanism between the host and th

[PATCH v3 net-next 1/1] hv_sock: implements Hyper-V transport for Virtual Sockets (AF_VSOCK)

ntroducing a new vsock transport for AF_VSOCK. Signed-off-by: Dexuan Cui <de...@microsoft.com> Cc: K. Y. Srinivasan <k...@microsoft.com> Cc: Haiyang Zhang <haiya...@microsoft.com> Cc: Stephen Hemminger <sthem...@microsoft.com> Cc: Andy King <ack...@vmware.com> Cc: Dmit

[PATCH v3 net-next 1/1] hv_sock: implements Hyper-V transport for Virtual Sockets (AF_VSOCK)

ntroducing a new vsock transport for AF_VSOCK. Signed-off-by: Dexuan Cui Cc: K. Y. Srinivasan Cc: Haiyang Zhang Cc: Stephen Hemminger Cc: Andy King Cc: Dmitry Torokhov Cc: George Zhang Cc: Jorgen Hansen Cc: Reilly Grant Cc: Asias He Cc: Stefan Hajnoczi Cc: Vitaly Kuznetsov Cc: Cathy Avery

RE: [PATCH v2 net-next 1/1] hv_sock: implements Hyper-V transport for Virtual Sockets (AF_VSOCK)

> From: David Miller [mailto:da...@davemloft.net] > Sent: Thursday, August 24, 2017 18:20 > > +#define VMBUS_PKT_TRAILER (sizeof(u64)) > > This is not the packet trailer, it's the size of the packet trailer. Thanks! I'll change it to VMBUS_PKT_TRAILER_SIZE. > > + /* Have we sent the

RE: [PATCH v2 net-next 1/1] hv_sock: implements Hyper-V transport for Virtual Sockets (AF_VSOCK)

> From: David Miller [mailto:da...@davemloft.net] > Sent: Thursday, August 24, 2017 18:20 > > +#define VMBUS_PKT_TRAILER (sizeof(u64)) > > This is not the packet trailer, it's the size of the packet trailer. Thanks! I'll change it to VMBUS_PKT_TRAILER_SIZE. > > + /* Have we sent the

[PATCH v2 net-next 1/1] hv_sock: implements Hyper-V transport for Virtual Sockets (AF_VSOCK)

ntroducing a new vsock transport for AF_VSOCK. Signed-off-by: Dexuan Cui <de...@microsoft.com> Cc: K. Y. Srinivasan <k...@microsoft.com> Cc: Haiyang Zhang <haiya...@microsoft.com> Cc: Stephen Hemminger <sthem...@microsoft.com> Cc: Andy King <ack...@vmware.com> Cc: Dmit

[PATCH v2 net-next 1/1] hv_sock: implements Hyper-V transport for Virtual Sockets (AF_VSOCK)

ntroducing a new vsock transport for AF_VSOCK. Signed-off-by: Dexuan Cui Cc: K. Y. Srinivasan Cc: Haiyang Zhang Cc: Stephen Hemminger Cc: Andy King Cc: Dmitry Torokhov Cc: George Zhang Cc: Jorgen Hansen Cc: Reilly Grant Cc: Stefan Hajnoczi Cc: Vitaly Kuznetsov Cc: Cathy Avery Cc: Rolf Neug

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

> From: Jorgen S. Hansen [mailto:jhan...@vmware.com] > > On Aug 22, 2017, at 11:54 AM, Stefan Hajnoczi > wrote: > > ... > > We *can* by looking at the destination CID. Please take a look at > > drivers/misc/vmw_vmci/vmci_route.c:vmci_route() to see how VMCI > handles > >

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

> From: Jorgen S. Hansen [mailto:jhan...@vmware.com] > > On Aug 22, 2017, at 11:54 AM, Stefan Hajnoczi > wrote: > > ... > > We *can* by looking at the destination CID. Please take a look at > > drivers/misc/vmw_vmci/vmci_route.c:vmci_route() to see how VMCI > handles > > nested virt. > > > > It

RE: [PATCH net-next 3/3] hv_sock: implements Hyper-V transport for Virtual Sockets (AF_VSOCK)

> From: Stefan Hajnoczi [mailto:stefa...@redhat.com] > On Fri, Aug 18, 2017 at 10:23:54PM +, Dexuan Cui wrote: > > > > +static bool hvs_stream_allow(u32 cid, u32 port) > > > > +{ > > > > + static const u32 valid_cids[]

RE: [PATCH net-next 3/3] hv_sock: implements Hyper-V transport for Virtual Sockets (AF_VSOCK)

> From: Stefan Hajnoczi [mailto:stefa...@redhat.com] > On Fri, Aug 18, 2017 at 10:23:54PM +, Dexuan Cui wrote: > > > > +static bool hvs_stream_allow(u32 cid, u32 port) > > > > +{ > > > > + static const u32 valid_cids[]

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

> From: Stefan Hajnoczi [mailto:stefa...@redhat.com] > > CID is not really used by us, because we only support guest<->host > communication, > > and don't support guest<->guest communication. The Hyper-V host > references > > every VM by VmID (which is invisible to the VM), and a VM can only talk

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

> From: Stefan Hajnoczi [mailto:stefa...@redhat.com] > > CID is not really used by us, because we only support guest<->host > communication, > > and don't support guest<->guest communication. The Hyper-V host > references > > every VM by VmID (which is invisible to the VM), and a VM can only talk

RE: [PATCH net-next 3/3] hv_sock: implements Hyper-V transport for Virtual Sockets (AF_VSOCK)

> From: Stefan Hajnoczi [mailto:stefa...@redhat.com] > Sent: Thursday, August 17, 2017 07:56 > To: Dexuan Cui <de...@microsoft.com> > On Tue, Aug 15, 2017 at 10:18:41PM +, Dexuan Cui wrote: > > +static u32 hvs_get_local_cid(void) > > +{ > > + return VMA

RE: [PATCH net-next 3/3] hv_sock: implements Hyper-V transport for Virtual Sockets (AF_VSOCK)

> From: Stefan Hajnoczi [mailto:stefa...@redhat.com] > Sent: Thursday, August 17, 2017 07:56 > To: Dexuan Cui > On Tue, Aug 15, 2017 at 10:18:41PM +0000, Dexuan Cui wrote: > > +static u32 hvs_get_local_cid(void) > > +{ > > + return VMADDR_CID_ANY; > > +}

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

> From: Stefan Hajnoczi [mailto:stefa...@redhat.com] > Sent: Thursday, August 17, 2017 07:06 > > On Tue, Aug 15, 2017 at 10:15:39PM +0000, Dexuan Cui wrote: > > With the current code, when vsock_dequeue_accept() is removing a sock > > from the list, nothing prevents vso

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

> From: Stefan Hajnoczi [mailto:stefa...@redhat.com] > Sent: Thursday, August 17, 2017 07:06 > > On Tue, Aug 15, 2017 at 10:15:39PM +0000, Dexuan Cui wrote: > > With the current code, when vsock_dequeue_accept() is removing a sock > > from the list, nothing prevents vso

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

> From: Jorgen S. Hansen [mailto:jhan...@vmware.com] > Sent: Thursday, August 17, 2017 08:17 > > > > Putting aside nested virtualization, I want to load the transport (vmci, > > Hyper-V, vsock) for which there is paravirtualized hardware present > > inside the guest. > > Good points. Completely

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

> From: Jorgen S. Hansen [mailto:jhan...@vmware.com] > Sent: Thursday, August 17, 2017 08:17 > > > > Putting aside nested virtualization, I want to load the transport (vmci, > > Hyper-V, vsock) for which there is paravirtualized hardware present > > inside the guest. > > Good points. Completely

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

> > On Aug 16, 2017, at 12:15 AM, Dexuan Cui <de...@microsoft.com> 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. W

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

> > 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

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

> From: David Miller [mailto:da...@davemloft.net] > Sent: Thursday, August 17, 2017 10:04 > I would avoid module parameters at all costs. > > It is the worst possible interface for users of your software. > > You really need to fundamentally solve the problems related to making > sure the proper

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

> From: David Miller [mailto:da...@davemloft.net] > Sent: Thursday, August 17, 2017 10:04 > I would avoid module parameters at all costs. > > It is the worst possible interface for users of your software. > > You really need to fundamentally solve the problems related to making > sure the proper

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

> From: Dexuan Cui > Sent: Wednesday, August 16, 2017 15:34 > > From: Jorgen S. Hansen [mailto:jhan...@vmware.com] > > > Without the patch, vmw_vsock_vmci_transport.ko and vmw_vmci.ko can > > > automatically load when an application creates an AF_VSOCK socket. > &g

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

> From: Dexuan Cui > Sent: Wednesday, August 16, 2017 15:34 > > From: Jorgen S. Hansen [mailto:jhan...@vmware.com] > > > Without the patch, vmw_vsock_vmci_transport.ko and vmw_vmci.ko can > > > automatically load when an application creates an AF_VSOCK socket. > &g

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

vsock_virtio_transport doesn't have the issue because it doesn't define MODULE_ALIAS_NETPROTO(PF_VSOCK). The patch also adds a module parameter "skip_hypervisor_check" for vmw_vsock_vmci_transport.ko. Signed-off-by: Dexuan Cui <de...@microsoft.com> Cc: Alok Kataria <akata...@v

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

vsock_virtio_transport doesn't have the issue because it doesn't define MODULE_ALIAS_NETPROTO(PF_VSOCK). The patch also adds a module parameter "skip_hypervisor_check" for vmw_vsock_vmci_transport.ko. Signed-off-by: Dexuan Cui Cc: Alok Kataria Cc: Andy King Cc: Adit Ranadive Cc: Ge

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

> From: Jorgen S. Hansen [mailto:jhan...@vmware.com] > > 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

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

> From: Jorgen S. Hansen [mailto:jhan...@vmware.com] > > 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

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

> From: David Miller [mailto:da...@davemloft.net] > Sent: Wednesday, August 16, 2017 11:07 > > From: Dexuan Cui <de...@microsoft.com> > Date: Tue, 15 Aug 2017 22:13:29 + > > > + /* > > +* Check if we are running on VMware's hype

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

> From: David Miller [mailto:da...@davemloft.net] > Sent: Wednesday, August 16, 2017 11:07 > > From: Dexuan Cui > Date: Tue, 15 Aug 2017 22:13:29 + > > > + /* > > +* Check if we are running on VMware's hypervisor and bail out > > +* if we are no

[PATCH] vmbus: don't acquire the mutex in vmbus_hvsock_device_unregister()

; vmbus_device_release(), we'll get a deadlock, because vmbus_device_release() tries to get the same mutex. Signed-off-by: Dexuan Cui <de...@microsoft.com> Cc: K. Y. Srinivasan <k...@microsoft.com> Cc: Haiyang Zhang <haiya...@microsoft.com> Cc: Stephen Hemminger <sthem...@micros

[PATCH] vmbus: don't acquire the mutex in vmbus_hvsock_device_unregister()

; vmbus_device_release(), we'll get a deadlock, because vmbus_device_release() tries to get the same mutex. Signed-off-by: Dexuan Cui Cc: K. Y. Srinivasan Cc: Haiyang Zhang Cc: Stephen Hemminger --- drivers/hv/channel_mgmt.c | 4 1 file changed, 4 deletions(-) diff --git a/drivers/hv/chann

[PATCH] vmbus: suppress uevents for hv_sock devices

of udevd, e.g. 30% on a 2-cpu virtual machine. So let's suppress the uevents to avoid this. Signed-off-by: Dexuan Cui <de...@microsoft.com> Cc: K. Y. Srinivasan <k...@microsoft.com> Cc: Haiyang Zhang <haiya...@microsoft.com> Cc: Stephen Hemminger <sthem...@microsoft.com> --- dr

[PATCH] vmbus: suppress uevents for hv_sock devices

of udevd, e.g. 30% on a 2-cpu virtual machine. So let's suppress the uevents to avoid this. Signed-off-by: Dexuan Cui Cc: K. Y. Srinivasan Cc: Haiyang Zhang Cc: Stephen Hemminger --- drivers/hv/vmbus_drv.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/hv/vmbus_drv.c b/drivers/hv

[PATCH net-next 3/3] hv_sock: implements Hyper-V transport for Virtual Sockets (AF_VSOCK)

ntroducing a new vsock transport for AF_VSOCK. Signed-off-by: Dexuan Cui <de...@microsoft.com> Cc: K. Y. Srinivasan <k...@microsoft.com> Cc: Haiyang Zhang <haiya...@microsoft.com> Cc: Stephen Hemminger <sthem...@microsoft.com> Cc: Andy King <ack...@vmware.com> Cc: Dmit

[PATCH net-next 3/3] hv_sock: implements Hyper-V transport for Virtual Sockets (AF_VSOCK)

ntroducing a new vsock transport for AF_VSOCK. Signed-off-by: Dexuan Cui Cc: K. Y. Srinivasan Cc: Haiyang Zhang Cc: Stephen Hemminger Cc: Andy King Cc: Dmitry Torokhov Cc: George Zhang Cc: Jorgen Hansen Cc: Reilly Grant Cc: Asias He Cc: Stefan Hajnoczi Cc: Vitaly Kuznetsov Cc: Cathy Avery

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

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. Signed-off-by: Dexuan Cui <de...@microsoft.com> Cc: Andy Kin

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

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. Signed-off-by: Dexuan Cui Cc: Andy King Cc: Dmitry Torokhov Cc: George

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

in hv_acpi_init(). KVM's vsock_virtio_transport doesn't have the issue because it doesn't define MODULE_ALIAS_NETPROTO(PF_VSOCK). Signed-off-by: Dexuan Cui <de...@microsoft.com> Cc: Alok Kataria <akata...@vmware.com> Cc: Andy King <ack...@vmware.com> Cc: Adit Ranadive <ad...@vmware.

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

in hv_acpi_init(). KVM's vsock_virtio_transport doesn't have the issue because it doesn't define MODULE_ALIAS_NETPROTO(PF_VSOCK). Signed-off-by: Dexuan Cui Cc: Alok Kataria Cc: Andy King Cc: Adit Ranadive Cc: George Zhang Cc: Jorgen Hansen Cc: K. Y. Srinivasan Cc: Haiyang Zhang Cc: Stephen

[PATCH net-next 0/3] add Hyper-V transport for Virtual Sockets

it manages to share the common vsock infrastructure to greatly reduce duplicate code, and avoid adding a new address family. The details are documented in PATCH 03. Dexuan Cui (3): VMCI: only load on VMware hypervisor vsock: fix vsock_dequeue/enqueue_accept race hv_sock: implements Hyper-V

[PATCH net-next 0/3] add Hyper-V transport for Virtual Sockets

it manages to share the common vsock infrastructure to greatly reduce duplicate code, and avoid adding a new address family. The details are documented in PATCH 03. Dexuan Cui (3): VMCI: only load on VMware hypervisor vsock: fix vsock_dequeue/enqueue_accept race hv_sock: implements Hyper-V

[PATCH] vmbus: fix the missed signaling in hv_signal_on_read()

ivers: hv: vmbus: finally fix hv_need_to_signal_on_read()") Signed-off-by: John Starks <john.sta...@microsoft.com> Signed-off-by: Dexuan Cui <de...@microsoft.com> Cc: Haiyang Zhang <haiya...@microsoft.com> Cc: Stephen Hemminger <sthem...@microsoft.com> Cc: "K. Y. Sr

[PATCH] vmbus: fix the missed signaling in hv_signal_on_read()

ivers: hv: vmbus: finally fix hv_need_to_signal_on_read()") Signed-off-by: John Starks Signed-off-by: Dexuan Cui Cc: Haiyang Zhang Cc: Stephen Hemminger Cc: "K. Y. Srinivasan" Cc: --- include/linux/hyperv.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff -

RE: [PATCH 1/1] Drivers: hv: vmbus: Don't leak channel ids

> From: linux-kernel-ow...@vger.kernel.org [mailto:linux-kernel- > ow...@vger.kernel.org] On Behalf Of k...@exchange.microsoft.com > > diff --git a/drivers/hv/channel_mgmt.c b/drivers/hv/channel_mgmt.c > index e1a3ae4..0a85246 100644 > --- a/drivers/hv/channel_mgmt.c > +++

RE: [PATCH 1/1] Drivers: hv: vmbus: Don't leak channel ids

> From: linux-kernel-ow...@vger.kernel.org [mailto:linux-kernel- > ow...@vger.kernel.org] On Behalf Of k...@exchange.microsoft.com > > diff --git a/drivers/hv/channel_mgmt.c b/drivers/hv/channel_mgmt.c > index e1a3ae4..0a85246 100644 > --- a/drivers/hv/channel_mgmt.c > +++

[PATCH] netvsc: fix use-after-free in netvsc_change_mtu()

'nvdev' is freed in rndis_filter_device_remove -> netvsc_device_remove -> free_netvsc_device, so we mustn't access it, before it's re-created in rndis_filter_device_add -> netvsc_device_add. Signed-off-by: Dexuan Cui <de...@microsoft.com> Cc: "K. Y. Srinivasan" <k..

[PATCH] netvsc: fix use-after-free in netvsc_change_mtu()

'nvdev' is freed in rndis_filter_device_remove -> netvsc_device_remove -> free_netvsc_device, so we mustn't access it, before it's re-created in rndis_filter_device_add -> netvsc_device_add. Signed-off-by: Dexuan Cui Cc: "K. Y. Srinivasan" Cc: Haiyang Zhang Cc: Stephen Hemm

[PATCH] vmbus: remove hv_event_tasklet_disable/enable

prematurely, cauing NULL dereferencing (the channel may haven't been properly configured to run the callback yet). Fixes: 631e63a9f346 ("vmbus: change to per channel tasklet") Signed-off-by: Dexuan Cui <de...@microsoft.com> Cc: "K. Y. Srinivasan" <k...@microsoft.com&g

[PATCH] vmbus: remove hv_event_tasklet_disable/enable

prematurely, cauing NULL dereferencing (the channel may haven't been properly configured to run the callback yet). Fixes: 631e63a9f346 ("vmbus: change to per channel tasklet") Signed-off-by: Dexuan Cui Cc: "K. Y. Srinivasan" Cc: Haiyang Zhang Cc: Stephen Hemminger --

RE: [PATCH] Drivers: hv: util: move waiting for release to hv_utils_transport itself

> From: Vitaly Kuznetsov [mailto:vkuzn...@redhat.com] > Sent: Thursday, March 2, 2017 17:48 > To: de...@linuxdriverproject.org > Cc: linux-kernel@vger.kernel.org; KY Srinivasan <k...@microsoft.com>; Haiyang > Zhang <haiya...@microsoft.com>; Stephen Hemminger > <st

RE: [PATCH] Drivers: hv: util: move waiting for release to hv_utils_transport itself

> From: Vitaly Kuznetsov [mailto:vkuzn...@redhat.com] > Sent: Thursday, March 2, 2017 17:48 > To: de...@linuxdriverproject.org > Cc: linux-kernel@vger.kernel.org; KY Srinivasan ; Haiyang > Zhang ; Stephen Hemminger > ; Dexuan Cui ; Alex Ng (LIS) > > Subject: [PATCH]

RE: [PATCH] Drivers: hv: util: on deinit, don't wait the release event, if we shouldn't

> From: Vitaly Kuznetsov [mailto:vkuzn...@redhat.com] (c) > >>> > > int (*on_msg)(void *, int); /* callback on new user > >>> > > message */ > >>> > > >>> > I think we can get away without introducing this new flag, e.g. if we > >>> > replace release_event with an atomic which will

RE: [PATCH] Drivers: hv: util: on deinit, don't wait the release event, if we shouldn't

> From: Vitaly Kuznetsov [mailto:vkuzn...@redhat.com] (c) > >>> > > int (*on_msg)(void *, int); /* callback on new user > >>> > > message */ > >>> > > >>> > I think we can get away without introducing this new flag, e.g. if we > >>> > replace release_event with an atomic which will

RE: [PATCH 1/1] Drivers: hv: util: on deinit, don't wait the release event, if we shouldn't

> From: k...@exchange.microsoft.com [mailto:k...@exchange.microsoft.com] > Sent: Tuesday, February 28, 2017 07:18 > To: gre...@linuxfoundation.org; linux-kernel@vger.kernel.org; > ... > From: Dexuan Cui <de...@microsoft.com> > > If the daemon is NOT running at all, when

RE: [PATCH 1/1] Drivers: hv: util: on deinit, don't wait the release event, if we shouldn't

> From: k...@exchange.microsoft.com [mailto:k...@exchange.microsoft.com] > Sent: Tuesday, February 28, 2017 07:18 > To: gre...@linuxfoundation.org; linux-kernel@vger.kernel.org; > ... > From: Dexuan Cui > > If the daemon is NOT running at all, when we disable the util

RE: [PATCH] Drivers: hv: util: on deinit, don't wait the release event, if we shouldn't

> From: devel [...] On Behalf Of Dexuan Cui > > > --- a/drivers/hv/hv_utils_transport.h > > > +++ b/drivers/hv/hv_utils_transport.h > > > @@ -32,6 +32,7 @@ struct hvutil_transport { > > > int mode; /* hvutil_transport_mode *

RE: [PATCH] Drivers: hv: util: on deinit, don't wait the release event, if we shouldn't

> From: devel [...] On Behalf Of Dexuan Cui > > > --- a/drivers/hv/hv_utils_transport.h > > > +++ b/drivers/hv/hv_utils_transport.h > > > @@ -32,6 +32,7 @@ struct hvutil_transport { > > > int mode; /* hvutil_transport_mode *

RE: [PATCH] Drivers: hv: util: on deinit, don't wait the release event, if we shouldn't

> From: Vitaly Kuznetsov [mailto:vkuzn...@redhat.com] > > void hv_fcopy_deinit(void) > > { > > + bool wait = hvt->dev_opened; > > + > > fcopy_transaction.state = HVUTIL_DEVICE_DYING; > > cancel_delayed_work_sync(_timeout_work); > > hvutil_transport_destroy(hvt); > > -

RE: [PATCH] Drivers: hv: util: on deinit, don't wait the release event, if we shouldn't

> From: Vitaly Kuznetsov [mailto:vkuzn...@redhat.com] > > void hv_fcopy_deinit(void) > > { > > + bool wait = hvt->dev_opened; > > + > > fcopy_transaction.state = HVUTIL_DEVICE_DYING; > > cancel_delayed_work_sync(_timeout_work); > > hvutil_transport_destroy(hvt); > > -

RE: [PATCH] Drivers: hv: util: on deinit, don't wait the release event, if we shouldn't

> From: Stephen Hemminger > Sent: Tuesday, February 28, 2017 01:02 > > The patch looks good. I don't understand the exact semantics here and > therefore have a couple of naïve questions > > Is it possible device could be opened multiple times? Is reference counting > done above? The file can

RE: [PATCH] Drivers: hv: util: on deinit, don't wait the release event, if we shouldn't

> From: Stephen Hemminger > Sent: Tuesday, February 28, 2017 01:02 > > The patch looks good. I don't understand the exact semantics here and > therefore have a couple of naïve questions > > Is it possible device could be opened multiple times? Is reference counting > done above? The file can

[PATCH] Drivers: hv: util: on deinit, don't wait the release event, if we shouldn't

elease -> ... -> kvp_on_reset -> complete(_event). Due to this, we even can't reboot the VM properly. The patch tracks if the dev file is opened or not, and we only need to wait if it's opened. Fixes: 5a66fecbf6aa ("Drivers: hv: util: kvp: Fix a rescind processing issue") Sign

[PATCH] Drivers: hv: util: on deinit, don't wait the release event, if we shouldn't

elease -> ... -> kvp_on_reset -> complete(_event). Due to this, we even can't reboot the VM properly. The patch tracks if the dev file is opened or not, and we only need to wait if it's opened. Fixes: 5a66fecbf6aa ("Drivers: hv: util: kvp: Fix a rescind processing issue") Signed-off-b

[PATCH] Drivers: hv: util: don't forget to init host_ts.lock

Without the patch, I always get a "BUG: spinlock bad magic" warning. Fixes: 3716a49a81ba ("hv_utils: implement Hyper-V PTP source") Signed-off-by: Dexuan Cui <de...@microsoft.com> Cc: Vitaly Kuznetsov <vkuzn...@redhat.com> Cc: "K. Y. Srinivasan" <

[PATCH] Drivers: hv: util: don't forget to init host_ts.lock

Without the patch, I always get a "BUG: spinlock bad magic" warning. Fixes: 3716a49a81ba ("hv_utils: implement Hyper-V PTP source") Signed-off-by: Dexuan Cui Cc: Vitaly Kuznetsov Cc: "K. Y. Srinivasan" Cc: Haiyang Zhang Cc: Stephen Hemminger --- 3716a49

RE: Boot regression (was "Re: [PATCH] genhd: Do not hold event lock when scheduling workqueue elements")

> From: h...@lst.de [mailto:h...@lst.de] > Sent: Wednesday, February 15, 2017 00:35 > > I tested today's linux-next (next-20170214) + the 2 patches just now and > got > > a weird result: > > sometimes the VM stills hung with a new calltrace (BUG: spinlock bad > > magic) , but sometimes the VM did

RE: Boot regression (was "Re: [PATCH] genhd: Do not hold event lock when scheduling workqueue elements")

> From: h...@lst.de [mailto:h...@lst.de] > Sent: Wednesday, February 15, 2017 00:35 > > I tested today's linux-next (next-20170214) + the 2 patches just now and > got > > a weird result: > > sometimes the VM stills hung with a new calltrace (BUG: spinlock bad > > magic) , but sometimes the VM did

RE: Boot regression (was "Re: [PATCH] genhd: Do not hold event lock when scheduling workqueue elements")

> From: h...@lst.de [mailto:h...@lst.de] > Sent: Tuesday, February 14, 2017 22:51 > To: Dexuan Cui <de...@microsoft.com> > Cc: h...@lst.de; Jens Axboe <ax...@kernel.dk>; Bart Van Assche > <bart.vanass...@sandisk.com>; h...@suse.com; h...@suse.de; Martin K. >

<    1   2   3   4   5   6   7   8   9   10   >