RE: [PATCH v3 0/7] PCI: PM: Move to D0 before calling pci_legacy_resume_early()

2019-10-15 Thread Dexuan Cui
> From: Bjorn Helgaas > Sent: Monday, October 14, 2019 4:00 PM > ... > > Dexuan, the important thing here is the first patch, which is your [1], > which I modified by doing pci_restore_state() as well as setting to D0: > > pci_set_power_state(pci_dev, PCI_D0); > pci_restore_state(pci_dev);

RE: [PATCH v2] PCI: PM: Move to D0 before calling pci_legacy_resume_early()

2019-10-08 Thread Dexuan Cui
> From: Bjorn Helgaas > Sent: Tuesday, October 8, 2019 12:56 PM > ... > Wordsmithing nit: what the patch does is not "fix the error message"; > what it does is fix the *problem*, i.e., the fact that we can't > operate the device because we can't enable MSI-X. The message is only > a symptom. I

RE: [PATCH v2] PCI: PM: Move to D0 before calling pci_legacy_resume_early()

2019-10-07 Thread Dexuan Cui
> -Original Message- > From: Bjorn Helgaas > Sent: Monday, October 7, 2019 6:24 AM > To: Dexuan Cui > Cc: lorenzo.pieral...@arm.com; linux-...@vger.kernel.org; Michael Kelley > ; linux-hyp...@vger.kernel.org; > linux-ker...@vger.kernel.org; driverdev-devel@linuxdri

RE: [PATCH v2] PCI: PM: Move to D0 before calling pci_legacy_resume_early()

2019-09-25 Thread Dexuan Cui
> From: devel On Behalf Of > Dexuan Cui > Sent: Monday, September 2, 2019 5:35 PM > To: lorenzo.pieral...@arm.com; bhelg...@google.com; > linux-...@vger.kernel.org > [..snipped...] > > --- > > > > changes in v2: > > Updated the changelog with more

RE: [PATCH v2] PCI: PM: Move to D0 before calling pci_legacy_resume_early()

2019-09-02 Thread Dexuan Cui
> From: Dexuan Cui > Sent: Tuesday, August 13, 2019 6:07 PM > To: lorenzo.pieral...@arm.com; bhelg...@google.com; > linux-...@vger.kernel.org > Cc: Michael Kelley ; linux-hyp...@vger.kernel.org; > linux-ker...@vger.kernel.org; driverdev-devel@linuxdriverproject.org; Sasha >

[PATCH v2] PCI: PM: Move to D0 before calling pci_legacy_resume_early()

2019-08-13 Thread Dexuan Cui
i_power_up() moves the device states back to PCI_D0. This path is not broken and doesn't need my patch. Signed-off-by: Dexuan Cui --- changes in v2: Updated the changelog with more details. drivers/pci/pci-driver.c | 7 --- 1 file changed, 4 insertions(+), 3 deletions(-) diff --gi

RE: [PATCH] PCI: PM: Also move to D0 before calling pci_legacy_resume_early()

2019-08-08 Thread Dexuan Cui
> From: Bjorn Helgaas > Sent: Thursday, August 8, 2019 12:19 PM > To: Dexuan Cui > > On Thu, Aug 08, 2019 at 06:46:51PM +0000, Dexuan Cui wrote: > > > > In pci_legacy_suspend_late(), the device state is moved to PCI_UNKNOWN. > > In pci_pm_thaw_noirq(), the s

[PATCH] PCI: PM: Also move to D0 before calling pci_legacy_resume_early()

2019-08-08 Thread Dexuan Cui
off-by: Dexuan Cui --- drivers/pci/pci-driver.c | 7 --- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/drivers/pci/pci-driver.c b/drivers/pci/pci-driver.c index 36dbe960306b..27dfc68db9e7 100644 --- a/drivers/pci/pci-driver.c +++ b/drivers/pci/pci-driver.c @@ -1074,15 +1074

RE: [PATCH v2] PCI: hv: Fix panic by calling hv_pci_remove_slots() earlier

2019-08-06 Thread Dexuan Cui
> From: linux-hyperv-ow...@vger.kernel.org > On Behalf Of Bjorn Helgaas > Sent: Tuesday, August 6, 2019 1:16 PM > To: Dexuan Cui > > Thanks for updating this. But you didn't update the subject line, > which is really still a little too low-level. Maybe Lorenzo will fix &g

[PATCH v2] PCI: hv: Fix panic by calling hv_pci_remove_slots() earlier

2019-08-02 Thread Dexuan Cui
The slot must be removed before the pci_dev is removed, otherwise a panic can happen due to use-after-free. Fixes: 15becc2b56c6 ("PCI: hv: Add hv_pci_remove_slots() when we unload the driver") Signed-off-by: Dexuan Cui Cc: sta...@vger.kernel.org --- Changes in v2: Improved the

RE: [PATCH] PCI: hv: Fix panic by calling hv_pci_remove_slots() earlier

2019-08-02 Thread Dexuan Cui
changelog in v2. :-) > On Fri, Aug 02, 2019 at 01:32:28AM +, Dexuan Cui wrote: > > > > When a slot is removed, the pci_dev must still exist. > > > > pci_remove_root_bus() removes and free all the pci_devs, so > > hv_pci_remove_slots() must be called befor

[PATCH] PCI: hv: Fix panic by calling hv_pci_remove_slots() earlier

2019-08-01 Thread Dexuan Cui
: 15becc2b56c6 ("PCI: hv: Add hv_pci_remove_slots() when we unload the driver") Signed-off-by: Dexuan Cui Cc: sta...@vger.kernel.org --- When pci-hyperv is unloaded, this panic can happen: general protection fault: CPU: 2 PID: 1091 Comm: rmmod Not tainted 5.2.0+ RIP: 0010:pci_sl

[PATCH v2] x86/hyper-v: Zero out the VP ASSIST PAGE to fix CPU offlining

2019-07-18 Thread Dexuan Cui
EOI MSR register irrespective of the "No EOI required" value, though by doing so we can't benefit from the optimization. Fixes: ba696429d290 ("x86/hyper-v: Implement EOI assist") Signed-off-by: Dexuan Cui --- v2: there is no code change. I just improved the comment and the chang

RE: [PATCH] x86/hyper-v: Zero out the VP assist page to fix CPU offlining

2019-07-18 Thread Dexuan Cui
> From: Thomas Gleixner > Sent: Thursday, July 18, 2019 12:56 AM > To: Dexuan Cui > > On Thu, 18 Jul 2019, Dexuan Cui wrote: > > > > The concept of the "overlay page" seems weird, and frankly speaking, > > I don't really understand why the Hyper-V guy

RE: [PATCH] x86/hyper-v: Zero out the VP assist page to fix CPU offlining

2019-07-18 Thread Dexuan Cui
> From: Thomas Gleixner > Sent: Thursday, July 18, 2019 12:01 AM > ... > Those are two different things. The GPF_ZERO allocation makes sense on its > own but it _cannot_ prevent the following scenario: Hi tglx, The scenario can be prevented. The VP ASSIST PAGE is an "overlay" page (please see

RE: [PATCH] x86/hyper-v: Zero out the VP assist page to fix CPU offlining

2019-07-17 Thread Dexuan Cui
> From: Thomas Gleixner > Sent: Wednesday, July 17, 2019 4:04 PM > To: Dexuan Cui > ... > On Thu, 4 Jul 2019, Dexuan Cui wrote: > > When a CPU is being offlined, the CPU usually still receives a few > > interrupts (e.g. reschedule IPIs),

[PATCH] x86/hyper-v: Zero out the VP assist page to fix CPU offlining

2019-07-03 Thread Dexuan Cui
r the VP ASSIST PAGE is disabled. Fixes: ba696429d290 ("x86/hyper-v: Implement EOI assist") Signed-off-by: Dexuan Cui --- arch/x86/hyperv/hv_init.c | 8 +++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/arch/x86/hyperv/hv_init.c b/arch/x86/hyperv/hv_init.c index 0e033ef11a9f..

[PATCH v2] PCI: hv: Fix a use-after-free bug in hv_eject_device_work()

2019-06-21 Thread Dexuan Cui
The commit 05f151a73ec2 itself is correct, but it exposes this use-after-free bug, which is caught by some memory debug options. Add a Fixes tag to indicate the dependency. Fixes: 05f151a73ec2 ("PCI: hv: Fix a memory leak in hv_eject_device_work()") Signed-off-by: Dexuan Cu

RE: [PATCH] PCI: hv: Fix a use-after-free bug in hv_eject_device_work()

2019-06-21 Thread Dexuan Cui
> From: Michael Kelley > > @@ -1880,6 +1880,7 @@ static void hv_pci_devices_present(struct > hv_pcibus_device > > *hbus, > > static void hv_eject_device_work(struct work_struct *work) > > { > > struct pci_eject_response *ejct_pkt; > > + struct hv_pcibus_device *hbus; > > struct

[PATCH] PCI: hv: Fix a use-after-free bug in hv_eject_device_work()

2019-06-21 Thread Dexuan Cui
The commit 05f151a73ec2 itself is correct, but it exposes this use-after-free bug, which is caught by some memory debug options. Add the Fixes tag to indicate the dependency. Fixes: 05f151a73ec2 ("PCI: hv: Fix a memory leak in hv_eject_device_work()") Signed-off-by: Dexuan Cu

[PATCH] Drivers: hv: vmbus: Fix virt_to_hvpfn() for X86_PAE

2019-05-07 Thread Dexuan Cui
ivers: hv: vmbus: Remove use of slow_virt_to_phys()") Cc: sta...@vger.kernel.org Cc: Michael Kelley Reported-and-tested-by: Juliana Rodrigueiro Signed-off-by: Dexuan Cui --- drivers/hv/channel.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/hv/channel.c b/

[PATCH] vmbus: Remove the undesired put_cpu_ptr() in hv_synic_cleanup()

2019-04-12 Thread Dexuan Cui
With CONFIG_DEBUG_PREEMPT=y, the put_cpu_ptr() triggiers an underflow warning in preempt_count_sub(). Fixes: 37cdd991fac8 ("vmbus: put related per-cpu variable together") Cc: sta...@vger.kernel.org Cc: Stephen Hemminger Signed-off-by: Dexuan Cui --- drivers/hv/hv.c | 1 - 1 file

RE: [PATCH 3/3] PCI: hv: Add pci_destroy_slot() in pci_devices_present_work(), if necessary

2019-03-26 Thread Dexuan Cui
> From: Lorenzo Pieralisi > Sent: Tuesday, March 26, 2019 12:55 PM > On Mon, Mar 04, 2019 at 09:34:49PM +0000, Dexuan Cui wrote: > > When we hot-remove a device, usually the host sends us a PCI_EJECT > message, > > and a PCI_BUS_RELATIONS message with bus_rel->device_co

RE: [PATCH 1/3] PCI: hv: Fix a memory leak in hv_eject_device_work()

2019-03-26 Thread Dexuan Cui
> From: Michael Kelley > Sent: Tuesday, March 26, 2019 10:47 AM > To: Lorenzo Pieralisi ; Dexuan Cui > > Cc: bhelg...@google.com; linux-...@vger.kernel.org; KY Srinivasan > ; Stephen Hemminger ; > Sasha Levin ; linux-hyp...@vger.kernel.org; > linux-ker...@vger.ker

RE: [PATCH 3/3] PCI: hv: Add pci_destroy_slot() in pci_devices_present_work(), if necessary

2019-03-20 Thread Dexuan Cui
> From: linux-hyperv-ow...@vger.kernel.org > On Behalf Of Dexuan Cui > > ... > > Patch 2 in this series does set it to NULL, but this code does not. > In Patch2, i.e. in the code path hv_pci_remove() -> hv_pci_remove_slots(), > we must set hpdev->pci_slot

RE: [PATCH 3/3] PCI: hv: Add pci_destroy_slot() in pci_devices_present_work(), if necessary

2019-03-20 Thread Dexuan Cui
> From: Michael Kelley > Sent: Wednesday, March 20, 2019 2:44 PM > To: Dexuan Cui ; lorenzo.pieral...@arm.com; > bhelg...@google.com; linux-...@vger.kernel.org; KY Srinivasan > > ... > > diff --git a/drivers/pci/controller/pci-hyperv.c > > @@ -

RE: [PATCH 1/3] PCI: hv: Fix a memory leak in hv_eject_device_work()

2019-03-20 Thread Dexuan Cui
> From: Michael Kelley > Sent: Wednesday, March 20, 2019 2:38 PM > > From: Dexuan Cui > > > > After a device is just created in new_pcichild_device(), hpdev->refs is set > > to 2 (i.e. the initial value of 1 plus the get_pcichild()). > > > > When we

[PATCH 1/3] PCI: hv: Fix a memory leak in hv_eject_device_work()

2019-03-04 Thread Dexuan Cui
4daace0d8ce8 ("PCI: hv: Add paravirtual PCI front-end for Microsoft Hyper-V VMs") Signed-off-by: Dexuan Cui Cc: --- drivers/pci/controller/pci-hyperv.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/pci/controller/pci-hyperv.c b/drivers/pci/controller/pci-hyperv.c i

[PATCH 0/3] pci-hyperv: fix memory leak and add pci_destroy_slot()

2019-03-04 Thread Dexuan Cui
s more work is required to make this scenaro work correctly, and since removing the driver is not really a "usual" usage, we can address this scenario in the future. Please review the patchset. Dexuan Cui (3): PCI: hv: Fix a memory leak in hv_eject_device_work() PCI: hv: Add hv_

[PATCH 3/3] PCI: hv: Add pci_destroy_slot() in pci_devices_present_work(), if necessary

2019-03-04 Thread Dexuan Cui
hv_pci_eject_device() to poll the channel's ringbuffer to work around the "hangs in hv_compose_msi_msg()" issue: see commit de0aa7b2f97d ("PCI: hv: Fix 2 hang issues in hv_compose_msi_msg()") Fixes: a15f2c08c708 ("PCI: hv: support reporting serial number as slot information"

[PATCH 2/3] PCI: hv: Add hv_pci_remove_slots() when we unload the driver

2019-03-04 Thread Dexuan Cui
root 0 Feb 7 10:49 2-1 drwxr-xr-x 2 root root 0 Feb 7 10:51 2-2 The patch adds the missing code. Fixes: a15f2c08c708 ("PCI: hv: support reporting serial number as slot information") Signed-off-by: Dexuan Cui Acked-by: Stephen Hemminger Cc: sta...@vger.kernel.org --- drivers/pc

RE: [PATCH] PCI: hv: Add hv_pci_remove_slots() when we unload the driver

2019-02-12 Thread Dexuan Cui
> From: Lorenzo Pieralisi > Sent: Tuesday, February 12, 2019 4:13 AM > ... > This patch fixes three bugs: > > 1) set hpdev->pci_slot to NULL > 2) move code destroying the slot inside a locked region in >hv_eject_device_work() > 3) Add missing slots removal code in hv_pci_remove() > > We

[PATCH] PCI: hv: Add hv_pci_remove_slots() when we unload the driver

2019-02-07 Thread Dexuan Cui
dds the missing code, and in hv_eject_device_work() it also moves pci_destroy_slot() to an earlier place where we hold the pci lock. Fixes: a15f2c08c708 ("PCI: hv: support reporting serial number as slot information") Signed-off-by: Dexuan Cui Cc: sta...@vger.kernel.org Cc: Steph

RE: [PATCH v2] nfit: add Hyper-V NVDIMM DSM command set to white list

2019-02-01 Thread Dexuan Cui
> From: Dan Williams > Sent: Friday, February 1, 2019 5:29 PM > ... > Honestly, the quickest path to something functional for Linux is to > simply delete the _LSR support and use raw mode defined namespaces. > Why have labels if they are read-only and the region is sufficient for > defining

RE: [PATCH v2] nfit: add Hyper-V NVDIMM DSM command set to white list

2019-02-01 Thread Dexuan Cui
> From: Dan Williams > Sent: Friday, February 1, 2019 5:29 PM > > ... > > The "size" and "mode" still don't look right, but the improvement is that > > now I can see a good descriptive "name", which I suppose is retrieved > > from Hyper-V. > > Mode is right, there is no way for Hyper-V to create

RE: [PATCH v2] nfit: add Hyper-V NVDIMM DSM command set to white list

2019-02-01 Thread Dexuan Cui
> From: Linux-nvdimm On Behalf Of > Dexuan Cui > Sent: Friday, February 1, 2019 4:34 PM > > > > ... > > > > Those reads find a namespace index block > > > > and a label. Unfortunately the label has the LOCAL flag set and Linux > > > > e

RE: [PATCH v2] nfit: add Hyper-V NVDIMM DSM command set to white list

2019-02-01 Thread Dexuan Cui
> From: Dan Williams > Sent: Friday, February 1, 2019 3:47 PM > To: Dexuan Cui > > I believe it's the same reason. Without 11189c1089da the _LSR method > will fail, and otherwise it works and finds the label that it doesn't > like. Exactly. > I'm not seeing "inva

RE: [PATCH v2] nfit: add Hyper-V NVDIMM DSM command set to white list

2019-02-01 Thread Dexuan Cui
> From: Dan Williams > Sent: Friday, February 1, 2019 9:29 AM > > Hi Dan, > > Unluckily it looks this commit causes a regression ... > > With the patch, "ndctl list" shows nothing, and /dev/pmem0 can't appear. > > If I revert the patch, it will be back to normal. > > > > I attached the

RE: [PATCH] Drivers: hv: vmbus: Add mutex lock to channel show functions

2019-02-01 Thread Dexuan Cui
> From: Kimberly Brown > Sent: Thursday, January 31, 2019 9:47 AM > ... > 2) Prevent a deadlock that can occur between the proposed mutex_lock() > call in the vmbus_chan_attr_show() function and the sysfs/kernfs functions. Hi Kim, Can you please share more details about the deadlock? It's

[PATCH] nfit: Document sysfs interface dirty_shutdown

2019-01-30 Thread Dexuan Cui
The new sysfs node was added in Sep 2018 in: commit 0ead11181fe0 ("acpi, nfit: Collect shutdown status") Now let's document it. Signed-off-by: Dexuan Cui --- Documentation/ABI/testing/sysfs-bus-nfit | 8 1 file changed, 8 insertions(+) diff --git a/Documentation/ABI/tes

RE: [PATCH] nfit: Collect shutdown status for NVDIMM_FAMILY_HYPERV

2019-01-30 Thread Dexuan Cui
> From: Linux-nvdimm On Behalf Of > Dexuan Cui > Sent: Wednesday, January 30, 2019 12:03 PM > To: Greg KH > Cc: Josh Poulson ; linux-nvd...@lists.01.org; > Haiyang Zhang ; > driverdev-devel@linuxdriverproject.org; Rafael J. Wysocki > ; linux-ker...@vger.kernel.org; Michae

RE: [PATCH] nfit: Collect shutdown status for NVDIMM_FAMILY_HYPERV

2019-01-30 Thread Dexuan Cui
> From: Greg KH > Sent: Wednesday, January 30, 2019 11:38 AM > > On Wed, Jan 30, 2019 at 06:48:40PM +0000, Dexuan Cui wrote: > > > > Let's expose the info to the userspace (e.g. ntctl) via sysfs. > > If you add a new sysfs file, you need to add a new Documentation/

[PATCH] nfit: Collect shutdown status for NVDIMM_FAMILY_HYPERV

2019-01-30 Thread Dexuan Cui
See http://www.uefi.org/RFIC_LIST ("Virtual NVDIMM 0x1901"): "Get Unsafe Shutdown Count (Function Index 2)". Let's expose the info to the userspace (e.g. ntctl) via sysfs. Signed-off-by: Dexuan Cui --- drivers/acpi/nfit/core.c | 51 +

[PATCH] nfit: acpi_nfit_ctl(): check out_obj->type in the right place

2019-01-29 Thread Dexuan Cui
In the case of ND_CMD_CALL, we should also check out_obj->type. The patch uses out_obj->type, which is a short alias to out_obj->package.type. Fixes: 31eca76ba2fc ("nfit, libnvdimm: limited/whitelisted dimm command marshaling mechanism") Cc: Signed-off-by: Dexuan Cui ---

RE: [PATCH] Drivers: hv: vmbus: Add mutex lock to channel show functions

2019-01-29 Thread Dexuan Cui
> From: Kimberly Brown > > ... > > But as you pointed, at least for sub-channels, channel->ringbuffer_page > > can indeed disappear in vmbus_close() -> ... -> vmbus_free_ring(), and > > the "attribute->show()" could crash when the race happens. > > Adding channel_mutex here seems to be able to

[PATCH v2] nfit: add Hyper-V NVDIMM DSM command set to white list

2019-01-28 Thread Dexuan Cui
Add the Hyper-V _DSM command set to the white list of NVDIMM command sets. This command set is documented at http://www.uefi.org/RFIC_LIST (see "Virtual NVDIMM 0x1901"). Thanks Dan Williams for writing the comment change. Signed-off-by: Dexuan Cui Reviewed-by: Michael Kelley --

RE: [PATCH] nfit: add Hyper-V NVDIMM DSM command set to white list

2019-01-28 Thread Dexuan Cui
> From: Dan Williams > Sent: Monday, January 28, 2019 1:55 PM > > On Mon, Jan 28, 2019 at 1:40 PM Dexuan Cui wrote: > > > I made the below simple change. Is this enough? Please suggest the proper > > wording/sentence, as I'm relatively new to NVDIMM, and I don'

RE: [PATCH] nfit: add Hyper-V NVDIMM DSM command set to white list

2019-01-28 Thread Dexuan Cui
> From: Dan Williams > Sent: Monday, January 28, 2019 1:01 PM > > Hi Dexuan, > Looks good. Just one update request and a note below... > > On Wed, Jan 23, 2019 at 12:51 PM Dexuan Cui wrote: > > ... > > --- a/drivers/acpi/nfit/core.c > > +++ b/drivers/

[PATCH] nfit: add Hyper-V NVDIMM DSM command set to white list

2019-01-23 Thread Dexuan Cui
Add the Hyper-V _DSM command set to the white list of NVDIMM command sets. This command set is documented at http://www.uefi.org/RFIC_LIST (see the link to "Virtual NVDIMM 0x1901" on the page). Signed-off-by: Dexuan Cui --- I'm going to change the user-space utility "ndctl&qu

RE: [PATCH] Drivers: hv: vmbus: Add mutex lock to channel show functions

2019-01-22 Thread Dexuan Cui
> From: Kimberly Brown > Sent: Monday, January 21, 2019 10:43 PM > > > @@ -1421,7 +1422,10 @@ static ssize_t vmbus_chan_attr_show(struct > > > kobject *kobj, > > > if (chan->state != CHANNEL_OPENED_STATE) > > > return -EINVAL; > > > > > > - return attribute->show(chan, buf); > > > +

RE: [PATCH] Drivers: hv: vmbus: Add mutex lock to channel show functions

2019-01-21 Thread Dexuan Cui
> From: Kimberly Brown > Sent: Monday, January 21, 2019 6:08 PM > Subject: [PATCH] Drivers: hv: vmbus: Add mutex lock to channel show functions > > The channel level "_show" functions are vulnerable to race conditions. > Add a mutex lock and unlock around the call to the channel level "_show" >

RE: [PATCH v3] Drivers: hv: vmbus: Expose counters for interrupts and full conditions

2019-01-16 Thread Dexuan Cui
> From: Kimberly Brown > Sent: Wednesday, January 16, 2019 8:38 PM > To: Michael Kelley ; Long Li > ; Sasha Levin ; > Dexuan Cui > Cc: KY Srinivasan ; Haiyang Zhang > ; Stephen Hemminger > ; de...@linuxdriverproject.org; > linux-ker...@vger.kernel.org > Subject:

RE: [PATCH v2] Drivers: hv: vmbus: Expose counters for interrupts and full conditions

2019-01-09 Thread Dexuan Cui
> From: Michael Kelley > Sent: Saturday, January 5, 2019 1:01 PM > > From: Kimberly Brown Sent: Friday, January 4, > > 2019 8:35 PM > > > > static inline void set_channel_pending_send_size(struct vmbus_channel *c, > > u32 size) > > { > > + if

RE: [PATCH v2] Drivers: hv: vmbus: Expose counters for interrupts and full conditions

2019-01-09 Thread Dexuan Cui
> From: Kimberly Brown > Sent: Friday, January 4, 2019 8:35 PM ... > +What: > /sys/bus/vmbus/devices//channels//intr_in_full > +Date: January 2019 > +KernelVersion: 4.21 There is no 4.21 version: see https://lkml.org/lkml/2019/1/6/178 :-) Thanks! -- Dexuan

[PATCH][re-post] vmbus: fix subchannel removal

2019-01-09 Thread Dexuan Cui
is processed. Without the fix, we have a lot of "hang" issues in netvsc when we try to change the NIC's MTU, set the number of channels, etc. Fixes: ae6935ed7d42 ("vmbus: split ring buffer allocation from open") Cc: sta...@vger.kernel.org Signed-off-by: Stephen Hemminger Signe

[PATCH] Drivers: hv: vmbus: Check for ring when getting debug info

2018-12-17 Thread Dexuan Cui
Haiyang Zhang Signed-off-by: Stephen Hemminger Signed-off-by: Dexuan Cui --- *NOTE*: the patch is based on char-misc's char-misc-linus branch. drivers/hv/ring_buffer.c | 31 - drivers/hv/vmbus_drv.c | 91 include/linux/hyperv.h |

RE: [PATCH] Drivers: hv: vmbus: Return -EINVAL for the sys files for unopened channels

2018-12-17 Thread Dexuan Cui
> From: devel On Behalf Of > Dexuan Cui > Sent: Monday, December 17, 2018 10:31 AM > > From: Stephen Hemminger > > > > The old code was risky because it would silently return stack garbage. > > Having an error check in get_debuginfo would eliminate that. >

RE: [PATCH] Drivers: hv: vmbus: Return -EINVAL for the sys files for unopened channels

2018-12-17 Thread Dexuan Cui
> From: Stephen Hemminger > Sent: Monday, December 17, 2018 10:17 AM > To: Dexuan Cui > > On Mon, 17 Dec 2018 18:00:29 +0000 > Dexuan Cui wrote: > > > > From: Stephen Hemminger > > > On Thu, 13 Dec 2018 16:35:43 + > > > Dexuan Cui wrote

RE: [PATCH] Drivers: hv: vmbus: Return -EINVAL for the sys files for unopened channels

2018-12-17 Thread Dexuan Cui
> From: Stephen Hemminger > On Thu, 13 Dec 2018 16:35:43 +0000 > Dexuan Cui wrote: > > > Before 98f4c651762c, we returned zeros for unopened channels. > > With 98f4c651762c, we started to return random on-stack values. > > > > We'd better return -EINVAL

[PATCH] Drivers: hv: vmbus: Return -EINVAL for the sys files for unopened channels

2018-12-13 Thread Dexuan Cui
ivasan Cc: Haiyang Zhang Cc: Stephen Hemminger Signed-off-by: Dexuan Cui --- drivers/hv/vmbus_drv.c | 20 1 file changed, 20 insertions(+) diff --git a/drivers/hv/vmbus_drv.c b/drivers/hv/vmbus_drv.c index 283d184..d0ff656 100644 --- a/drivers/hv/vmbus_drv.c +++ b/drivers/hv/v

RE: [PATCH] vmbus: fix subchannel removal

2018-12-09 Thread Dexuan Cui
> From: Stephen Hemminger > Sent: Friday, December 7, 2018 10:59 AM > To: KY Srinivasan ; Haiyang Zhang > ; Dexuan Cui ; > mga...@redhat.com > Cc: de...@linuxdriverproject.org; Stephen Hemminger > > Subject: [PATCH] vmbus: fix subchannel removal > > The changes

[PATCH] [REPOST for the char-misc-linus branch] Drivers: hv: vmbus: Offload the handling of channels to two workqueues

2018-12-02 Thread Dexuan Cui
g kernels, not only the kernels that have 8195b1396ec8. Fixes: 8195b1396ec8 ("hv_netvsc: fix deadlock on hotplug") Cc: sta...@vger.kernel.org Cc: Stephen Hemminger Cc: K. Y. Srinivasan Cc: Haiyang Zhang Signed-off-by: Dexuan Cui Signed-off-by: K. Y. Srinivasan --- [Dec. 2, 2018] Dexuan: I

RE: [PATCH] [repost] Drivers: hv: vmbus: Offload the handling of channels to two workqueues

2018-12-02 Thread Dexuan Cui
> From: gre...@linuxfoundation.org > Sent: Sunday, December 2, 2018 7:33 AM > To: Dexuan Cui > Cc: KY Srinivasan ; Haiyang Zhang > ; Stephen Hemminger > ; linux-ker...@vger.kernel.org; > de...@linuxdriverproject.org; a...@canonical.com; vkuznets > ; o...@aepfle.de; jaso

RE: [PATCH] [repost] Drivers: hv: vmbus: Offload the handling of channels to two workqueues

2018-12-02 Thread Dexuan Cui
> From: gre...@linuxfoundation.org > Sent: Saturday, December 1, 2018 11:34 PM > To: Dexuan Cui > Cc: KY Srinivasan ; Haiyang Zhang > ; Stephen Hemminger > ; linux-ker...@vger.kernel.org; > de...@linuxdriverproject.org; a...@canonical.com; vkuznets > ; o...@aepfle

RE: [PATCH] [repost] Drivers: hv: vmbus: Offload the handling of channels to two workqueues

2018-11-30 Thread Dexuan Cui
> From: KY Srinivasan > Sent: Friday, November 30, 2018 9:31 AM > > From: Dexuan Cui > > Sent: Thursday, November 29, 2018 12:17 AM > > To: gre...@linuxfoundation.org > > Cc: KY Srinivasan ; Haiyang Zhang > > ; Stephen Hemminger > &

RE: [PATCH] [repost] Drivers: hv: vmbus: Offload the handling of channels to two workqueues

2018-11-29 Thread Dexuan Cui
> From: gre...@linuxfoundation.org > Sent: Wednesday, November 28, 2018 11:45 PM > > > > There is no change in this repost. I just rebased this patch to today's > > char-misc's char-misc-next branch. Previously KY posted the patch with his > > Signed-off-by (which is kept in this repost), but

[PATCH] [repost] Drivers: hv: vmbus: Offload the handling of channels to two workqueues

2018-11-28 Thread Dexuan Cui
g kernels, not only the kernels that have 8195b1396ec8. Fixes: 8195b1396ec8 ("hv_netvsc: fix deadlock on hotplug") Cc: sta...@vger.kernel.org Cc: Stephen Hemminger Cc: K. Y. Srinivasan Cc: Haiyang Zhang Signed-off-by: Dexuan Cui Signed-off-by: K. Y. Srinivasan --- There is no change in

RE: [PATCH 2/2] Drivers: hv: vmbus: offload the handling of channels to two workqueues

2018-11-26 Thread Dexuan Cui
> From: devel On Behalf Of > Greg KH > Sent: Monday, November 26, 2018 11:35 AM > As Sasha pointed out, this patch does not even apply :( Sorry, I'll rebase to char-misc's char-misc-testing branch, which has had one of the patches, i.e. 4d3c5c69191f ("Drivers: hv: vmbus: Remove the useless API

RE: [PATCH V2 3/5] Drivers: hv: kvp: Fix the recent regression caused by incorrect clean-up

2018-11-10 Thread Dexuan Cui
> From: gre...@linuxfoundation.org > Sent: Thursday, November 1, 2018 21:54 > To: Dexuan Cui > Cc: Michael Kelley ; KY Srinivasan > ; linux-ker...@vger.kernel.org; > de...@linuxdriverproject.org; o...@aepfle.de; a...@canonical.com; > jasow...@redhat.com; Stephen Hemminger

RE: [PATCH V2 3/5] Drivers: hv: kvp: Fix the recent regression caused by incorrect clean-up

2018-11-01 Thread Dexuan Cui
> From: gre...@linuxfoundation.org > Sent: Thursday, November 1, 2018 11:57 > To: Dexuan Cui > > On Wed, Oct 31, 2018 at 11:23:54PM +0000, Dexuan Cui wrote: > > > From: Michael Kelley > > > Sent: Wednesday, October 24, 2018 08:38 > > > From:

RE: [PATCH V2 3/5] Drivers: hv: kvp: Fix the recent regression caused by incorrect clean-up

2018-10-31 Thread Dexuan Cui
> From: Michael Kelley > Sent: Wednesday, October 24, 2018 08:38 > From: k...@linuxonhyperv.com Sent: Wednesday, > October 17, 2018 10:10 PM > > From: Dexuan Cui > > > > In kvp_send_key(), we do need call process_ib_ipinfo() if > > message->kvp_hdr.o

RE: [PATCH 5/5] Tools: hv: kvp: Fix a warning of buffer overflow with gcc 8.0.1

2018-10-17 Thread Dexuan Cui
> From: devel On Behalf Of > Greg KH > Sent: Tuesday, October 16, 2018 22:07 > > On Wed, Oct 17, 2018 at 03:14:06AM +, k...@linuxonhyperv.com wrote: > > From: Dexuan Cui > > > > The patch fixes: > > > > hv_kvp_daemon.c: In function 'kvp_s

RE: [PATCH 3/5] Drivers: hv: kvp: Fix the recent regression caused by incorrect clean-up

2018-10-17 Thread Dexuan Cui
> From: devel On Behalf Of > Greg KH > Sent: Tuesday, October 16, 2018 22:07 > > ... > > + case KVP_OP_GET: > > + message->body.kvp_get.data.key_size = > > + utf16s_to_utf8s( > > + (wchar_t *)in_msg->body.kvp_get.data.key, > > +

RE: [PATCH 3/5] Drivers: hv: kvp: Fix the recent regression caused by incorrect clean-up

2018-10-17 Thread Dexuan Cui
> From: devel On Behalf Of > KY Srinivasan > Sent: Tuesday, October 16, 2018 23:02 > > > --- a/drivers/hv/hv_kvp.c > > > +++ b/drivers/hv/hv_kvp.c > > > @@ -353,6 +353,9 @@ static void process_ib_ipinfo(void *in_msg, void > > *out_msg, int op) > > > > > >

[tip:x86/hyperv] x86/hyperv: Suppress "PCI: Fatal: No config space access function found"

2018-09-27 Thread tip-bot for Dexuan Cui
Commit-ID: 2f285f46240d67060061d153786740d4df53cd78 Gitweb: https://git.kernel.org/tip/2f285f46240d67060061d153786740d4df53cd78 Author: Dexuan Cui AuthorDate: Tue, 18 Sep 2018 22:29:50 + Committer: Thomas Gleixner CommitDate: Thu, 27 Sep 2018 21:19:14 +0200 x86/hyperv: Suppress

[PATCH] x86/hyperv: suppress "PCI: Fatal: No config space access function found"

2018-09-18 Thread Dexuan Cui
A Generatin-2 Linux VM on Hyper-V doesn't have the legacy PCI bus, and users always see the scary warning, which is actually harmless. The patch is made to suppress the warning. Signed-off-by: Dexuan Cui Cc: K. Y. Srinivasan Cc: Haiyang Zhang Cc: Stephen Hemminger --- arch/x86/hyperv

RE: [PATCH] Drivers: hv: vmbus: Use raw_smp_processor_id() in vmbus_connect()

2018-08-30 Thread Dexuan Cui
> From: KY Srinivasan > Sent: Thursday, August 30, 2018 10:32 > > > */ > > >if (version >= VERSION_WIN8_1) { > > >msg->target_vcpu = > > > -hv_cpu_number_to_vp_number(smp_processor_id()); > > > - vmbus_connection.connect_cpu = smp_processor_id(); > > > > > +

RE: [PATCH] Drivers: hv: vmbus: Use raw_smp_processor_id() in vmbus_connect()

2018-08-30 Thread Dexuan Cui
> From: KY Srinivasan > Sent: Thursday, August 30, 2018 09:28 > ... > diff --git a/drivers/hv/connection.c b/drivers/hv/connection.c > @@ -119,8 +119,9 @@ static int vmbus_negotiate_version(struct > vmbus_channel_msginfo *msginfo, > */ >if (version >= VERSION_WIN8_1) { >

[PATCH v2] hv_netvsc: Fix a deadlock by getting rtnl lock earlier in netvsc_probe()

2018-08-29 Thread Dexuan Cui
the locks, so #1 and #3 will not be blocked for ever. Fixes: 8195b1396ec8 ("hv_netvsc: fix deadlock on hotplug") Signed-off-by: Dexuan Cui Cc: Stephen Hemminger Cc: K. Y. Srinivasan Cc: Haiyang Zhang --- This v2 is a resend of v1, but the commit log is updated: 1. moved the text after th

RE: [PATCH] hv_netvsc: Fix a deadlock by getting rtnl_lock earlier in netvsc_probe()

2018-08-29 Thread Dexuan Cui
> From: David Miller > Sent: Wednesday, August 29, 2018 19:09 > > Hi David, > > I was afraid the call-traces are too detailed. :-) > > > > Can you please move the info to before the --- line? > > > > Or, should I resend the patch with the commit log updated? > > Please resend. OK. Will do. --

RE: [PATCH] hv_netvsc: Fix a deadlock by getting rtnl_lock earlier in netvsc_probe()

2018-08-29 Thread Dexuan Cui
> From: David Miller > Sent: Wednesday, August 29, 2018 17:49 > > From: Dexuan Cui > Date: Wed, 22 Aug 2018 21:20:03 + > > > --- > > drivers/net/hyperv/netvsc_drv.c | 11 ++- > > 1 file changed, 10 insertions(+), 1 deletion(-) > > > &

[PATCH] Drivers: hv: vmbus: Use raw_smp_processor_id() in vmbus_connect()

2018-08-23 Thread Dexuan Cui
and an interrupt on CPU msg->target_vcpu, and later the interrupt handler will wake up vmbus_connect(). vmbus_connect() doesn't really have to run on the same cpu as CPU msg->target_vcpu, so it's safe to use raw_smp_processor_id() here. Signed-off-by: Dexuan Cui Cc: sta...@vger.kernel.org Cc

[PATCH] hv_netvsc: Fix a deadlock by getting rtnl_lock earlier in netvsc_probe()

2018-08-22 Thread Dexuan Cui
This patch fixes the race between netvsc_probe() and rndis_set_subchannel(), which can cause a deadlock. Fixes: 8195b1396ec8 ("hv_netvsc: fix deadlock on hotplug") Signed-off-by: Dexuan Cui Cc: Stephen Hemminger Cc: K. Y. Srinivasan Cc: Haiyang Zhang --- drivers/net/hyperv/ne

[PATCH] Drivers: hv: vmbus: Reset the channel callback in vmbus_onoffer_rescind()

2018-07-12 Thread Dexuan Cui
range protected by disabling/enabling channel->callback_event: we don't really need that for the whole function. Signed-off-by: Dexuan Cui Cc: sta...@vger.kernel.org Cc: K. Y. Srinivasan Cc: Stephen Hemminger Cc: Michael Kelley --- drivers/hv/channel.c | 40 -

[PATCH v2] PCI: hv: Disable/enable irq rather than bh in hv_compose_msi_msg()

2018-07-01 Thread Dexuan Cui
ore() instead. Note: hv_pci_onchannelcallback() is not a hot path because it's only called when the PCI device is hot added and removed, which is infrequent. Fixes: de0aa7b2f97d ("PCI: hv: Fix 2 hang issues in hv_compose_msi_msg()") Signed-off-by: Dexuan Cui Reviewed-by: Haiyang Zhang Cc: C

RE: [PATCH] PCI: hv: Fix a __local_bh_enable_ip warning in hv_compose_msi_msg()

2018-06-30 Thread Dexuan Cui
> From: Lorenzo Pieralisi > Sent: Friday, June 29, 2018 02:39 > To: Dexuan Cui > On Wed, Jun 13, 2018 at 10:50:05PM +0000, Dexuan Cui wrote: > > > From: Bjorn Helgaas > > > Sent: Wednesday, June 13, 2018 15:15 > > > > ... > > > > It looks Lo

RE: [PATCH] PCI: hv: Fix a __local_bh_enable_ip warning in hv_compose_msi_msg()

2018-06-13 Thread Dexuan Cui
> From: Bjorn Helgaas > Sent: Wednesday, June 13, 2018 15:15 > > ... > > It looks Lorenzo's pci.git tree has not been updated for 3+ weeks. > > I guess Lorenzo may be on vacation. > > > > @Bjorn, can this patch go through your tree? > > Should I resubmit it? > > No need to resubmit it, Lorenzo

RE: [PATCH] PCI: hv: Fix a __local_bh_enable_ip warning in hv_compose_msi_msg()

2018-06-13 Thread Dexuan Cui
> From: Dexuan Cui > Sent: Wednesday, June 6, 2018 17:15 > To: Haiyang Zhang ; Lorenzo Pieralisi > ; Bjorn Helgaas ; > linux-...@vger.kernel.org; KY Srinivasan ; Stephen > Hemminger ; o...@aepfle.de; > a...@canonical.com; jasow...@redhat.com > Cc: linux-ker...@vger.ker

RE: [PATCH v4] Drivers: HV: Send one page worth of kmsg dump over Hyper-V during panic

2018-06-06 Thread Dexuan Cui
> From: Sunil Muthuswamy > Sent: Wednesday, June 6, 2018 12:31 > ... > + int sysctl_record_panic_msg = 1; This variable can be static. -- Dexuan ___ devel mailing list de...@linuxdriverproject.org

RE: [PATCH] PCI: hv: Fix a __local_bh_enable_ip warning in hv_compose_msi_msg()

2018-06-06 Thread Dexuan Cui
> From: Haiyang Zhang > Sent: Friday, May 25, 2018 12:52 > To: Dexuan Cui ; Lorenzo Pieralisi > ; Bjorn Helgaas ; > linux-...@vger.kernel.org; KY Srinivasan ; Stephen > Hemminger ; o...@aepfle.de; > a...@canonical.com; jasow...@redhat.com > Cc: linux-ker...@vger.ker

RE: [PATCH] hv_netvsc: Fix a network regression after ifdown/ifup

2018-06-06 Thread Dexuan Cui
> From: Stephen Hemminger > Sent: Wednesday, June 6, 2018 14:07 > ... > Ok, just skip the check and big comment. > wake all queues is harmless if they are already awake. Ok, I'll post a v2 without the check and the comment shortly. -- Dexuan ___ devel

[PATCH v2] hv_netvsc: Fix a network regression after ifdown/ifup

2018-06-06 Thread Dexuan Cui
et up: see rndis_set_subchannel() -> netif_device_attach(), but in the case of "ifdown eth0; ifup eth0" where the number of channels doesn't change, we also must make sure the TX queues are enabled. The patch fixes the regression. Fixes: 7b2ee50c0cd5 ("hv_netvsc: common detach logic

[PATCH] hv_netvsc: Fix a network regression after ifdown/ifup

2018-06-06 Thread Dexuan Cui
Recently people reported the NIC stops working after "ifdown eth0; ifup eth0". It turns out in this case the TX queues are not enabled, after the refactoring of the common detach logic. The patch fixes the regression. Fixes: 7b2ee50c0cd5 ("hv_netvsc: common detach logic") S

RE: [PATCH] PCI: hv: Do not wait forever on a device that has disappeared

2018-05-31 Thread Dexuan Cui
> From: Michael Kelley (EOSG) > Sent: Thursday, May 31, 2018 09:41 > > > > IMO we can disable the per-channel tasklet to exclude the race: > > This way, when we exit the loop, we're sure hv_pci_onchannelcallback() can > > not run anymore. What do you think of this? > > I've stared at this and the

RE: [PATCH] PCI: hv: Do not wait forever on a device that has disappeared

2018-05-29 Thread Dexuan Cui
> From: Andy Shevchenko > Sent: Tuesday, May 29, 2018 14:21 > On Thu, May 24, 2018 at 12:12 AM, Dexuan Cui > wrote: > > > > Before the guest finishes the device initialization, the device can be > > removed anytime by the host, and after that the host won't respond

RE: [PATCH] PCI: hv: Do not wait forever on a device that has disappeared

2018-05-29 Thread Dexuan Cui
> From: Michael Kelley (EOSG) > Sent: Monday, May 28, 2018 17:19 > > While this patch solves the immediate problem of getting hung waiting > for a response from Hyper-V that will never come, there's another scenario > to look at that I think introduces a race. Suppose the guest VM issues a >

RE: [PATCH] PCI: hv: Do not wait forever on a device that has disappeared

2018-05-24 Thread Dexuan Cui
> From: Lorenzo Pieralisi <lorenzo.pieral...@arm.com> > Sent: Thursday, May 24, 2018 05:41 > On Wed, May 23, 2018 at 09:12:01PM +0000, Dexuan Cui wrote: > > > > Before the guest finishes the device initialization, the device can be > > removed anytime by the ho

[PATCH] PCI: hv: Do not wait forever on a device that has disappeared

2018-05-23 Thread Dexuan Cui
Before the guest finishes the device initialization, the device can be removed anytime by the host, and after that the host won't respond to the guest's request, so the guest should be prepared to handle this case. Signed-off-by: Dexuan Cui <de...@microsoft.com> Cc: Stephen Hemminger

[PATCH] PCI: hv: Fix a __local_bh_enable_ip warning in hv_compose_msi_msg()

2018-05-22 Thread Dexuan Cui
warning by switching to local_irq_save()/restore(). This is not an issue because hv_pci_onchannelcallback() is not slow, and it not a hot path. Fixes: de0aa7b2f97d ("PCI: hv: Fix 2 hang issues in hv_compose_msi_msg()") Signed-off-by: Dexuan Cui <de...@microsoft.com> Cc: <sta...@vger.k

RE: [PATCH] tools: hv: lsvmbus: convert to Python3

2018-05-22 Thread Dexuan Cui
dev_desc, d.chn_vp_mapping)) > else: > - print ('VMBUS ID ' + format2) % \ > + print(('VMBUS ID ' + format2) % \ > (d.vmbus_id, d.class_id, d.dev_desc, \ > - d.device_id, d.sysfs_path, d.chn_vp_mapping) &

  1   2   3   4   5   6   >