RE: linux-next: manual merge of the char-misc tree with the char-misc.current tree

2018-12-04 Thread Dexuan Cui
> From: Greg KH > Sent: Monday, December 3, 2018 11:43 PM > On Tue, Dec 04, 2018 at 03:35:13PM +1100, Stephen Rothwell wrote: > > Hi all, > > > > Today's linux-next merge of the char-misc tree got a conflict in: > > > > drivers/hv/channel_mgmt.c > > > > between commit: > > > > 37c2578c0c40

[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-kernel@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-kernel@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 1/2] Drivers: hv: vmbus: check the creation_status in vmbus_establish_gpadl()

2018-11-26 Thread Dexuan Cui
> From: Sasha Levin > Sent: Monday, November 26, 2018 1:53 AM > Hi, > > [This is an automated email] > > This commit has been processed because it contains a -stable tag. > The stable tag indicates that it's relevant for the following trees: all > > The bot has tested the following trees:

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-kernel@vger.kernel.org; > de...@linuxdriverproject.org; o...@aepfle.de; a...@canonical.com; > jasow...@redhat.com; Stephen Hemminger

RE: Will the recent memory leak fixes be backported to longterm kernels?

2018-11-01 Thread Dexuan Cui
> From: Roman Gushchin > Sent: Thursday, November 1, 2018 17:58 > > On Fri, Nov 02, 2018 at 12:16:02AM +0000, Dexuan Cui wrote: > Hello, Dexuan! > > A couple of issues has been revealed recently, here are fixes > (hashes are from the next tree): > > 5f4b045

Will the recent memory leak fixes be backported to longterm kernels?

2018-11-01 Thread Dexuan Cui
Hi all, When debugging a memory leak issue (https://github.com/coreos/bugs/issues/2516) with v4.14.11-coreos, we noticed the same issue may have been fixed recently by Roman in the latest mainline (i.e. Linus's master branch) according to comment #7 of

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 AUTOSEL 4.19 109/146] Drivers: hv: kvp: Fix two "this statement may fall through" warnings

2018-10-31 Thread Dexuan Cui
> From: Sasha Levin > Sent: Wednesday, October 31, 2018 16:05 > To: sta...@vger.kernel.org; linux-kernel@vger.kernel.org > Cc: Dexuan Cui ; KY Srinivasan ; > Haiyang Zhang ; Stephen Hemminger > ; sta...@vger.kernel.org; Greg Kroah-Hartman > ; Sasha Levin > Subject: [PA

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

[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

[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: 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) > + d.device_id, d.sysfs_path, d.chn_vp_mapping)) > -- > 2.14.3 Looks good to me. Thanks! Acked-by: Dexuan Cui <de...@microsoft.com>

[tip:timers/urgent] tick/broadcast: Use for_each_cpu() specially on UP kernels

2018-05-15 Thread tip-bot for Dexuan Cui
Commit-ID: 5596fe34495cf0f645f417eb928ef224df3e3cb4 Gitweb: https://git.kernel.org/tip/5596fe34495cf0f645f417eb928ef224df3e3cb4 Author: Dexuan Cui <de...@microsoft.com> AuthorDate: Tue, 15 May 2018 19:52:50 + Committer: Thomas Gleixner <t...@linutronix.de> CommitDate:

RE: for_each_cpu() is buggy for UP kernel?

2018-05-15 Thread Dexuan Cui
> From: Linus Torvalds <torva...@linux-foundation.org> > Sent: Tuesday, May 15, 2018 10:22 > To: Dexuan Cui <de...@microsoft.com> > > On Mon, May 14, 2018 at 8:02 PM Dexuan Cui <de...@microsoft.com> wrote: > > > If you're OK with the below

[PATCH] tick/broadcast: Use for_each_cpu() specially on UP kernels

2018-05-15 Thread Dexuan Cui
minutes during boot-up, and sometimes it can hang forever. Link: https://lkml.org/lkml/2018/5/9/63 Link: https://lkml.org/lkml/2018/5/15/747 Signed-off-by: Dexuan Cui <de...@microsoft.com> Cc: sta...@vger.kernel.org --- Some part of the changelog and comments are copied from Thomas Glei

RE: for_each_cpu() is buggy for UP kernel?

2018-05-14 Thread Dexuan Cui
> From: Linus Torvalds <torva...@linux-foundation.org> > Sent: Sunday, May 13, 2018 11:22 > On Tue, May 8, 2018 at 11:24 PM Dexuan Cui <de...@microsoft.com> wrote: > > > Should we fix the for_each_cpu() in include/linux/cpumask.h for UP? > > As Thomas

[PATCH] Drivers: hv: vmbus: Removed an unnecessary cast from void *

2018-05-14 Thread Dexuan Cui
In C, we don't need such a cast. Fixes: ae20b254306a ("Drivers: hv: vmbus: enable VMBus protocol version 5.0") Signed-off-by: Dexuan Cui <de...@microsoft.com> Cc: Stephen Hemminger <sthem...@microsoft.com> Cc: K. Y. Srinivasan <k...@microsoft.com> --- Thanks St

RE: [PATCH 1/1] Drivers: hv: vmbus: enable VMBus protocol version 5.0

2018-05-14 Thread Dexuan Cui
> From: Stephen Hemminger <step...@networkplumber.org> > Sent: Monday, May 14, 2018 11:18 > To: Dexuan Cui <de...@microsoft.com> > > > ... > > > Hate to pick o the details, but buffer is void * so cast is not necessary > > > here. > > >

RE: [PATCH 1/1] Drivers: hv: vmbus: enable VMBus protocol version 5.0

2018-05-14 Thread Dexuan Cui
> From: devel On Behalf Of > Stephen Hemminger > Sent: Sunday, May 13, 2018 10:24 > > ... > > @@ -372,6 +400,18 @@ int vmbus_post_msg(void *buffer, size_t buflen, > bool can_sleep) > > ... > > + hdr = (struct

for_each_cpu() is buggy for UP kernel?

2018-05-09 Thread Dexuan Cui
In include/linux/cpumask.h, for_each_cpu is defined like this for UP kernel (CONFIG_NR_CPUS=1): #define for_each_cpu(cpu, mask) \ for ((cpu) = 0; (cpu) < 1; (cpu)++, (void)mask) Here 'mask' is ignored, but what if 'mask' contains 0 CPU? -- in this case, the for loop

RE: [PATCH] Drivers: hv: vmbus: enable VMBus protocol version 5.0

2018-05-08 Thread Dexuan Cui
> From: Stephen Hemminger <step...@networkplumber.org> > Sent: Tuesday, May 8, 2018 15:45 > On Tue, 8 May 2018 22:26:21 +0000 > Dexuan Cui <de...@microsoft.com> wrote: > > > @@ -63,6 +63,9 @@ static __u32 vmbus_get_next_version(__u32 > current_

[PATCH] Drivers: hv: vmbus: enable VMBus protocol version 5.0

2018-05-08 Thread Dexuan Cui
VersionResponse Message. 4) It's possible that the primary VMBus driver using protocol version 4.0 can work with a secondary VMBus driver using protocol version 5.0, but it's recommended that both should use 5.0 for new Hyper-V features in the future. Signed-off-by: Dexuan Cui <de...@microsoft.com> Cc: S

[PATCH] Drivers: hv: vmbus: Fix the offer_in_progress in vmbus_process_offer()

2018-04-26 Thread Dexuan Cui
I didn't really hit a real bug, but just happened to spot the bug: we have decreased the counter at the beginning of vmbus_process_offer(), so we mustn't decrease it again. Fixes: 6f3d791f3006 ("Drivers: hv: vmbus: Fix rescind handling issues") Signed-off-by: Dexuan Cui <de...@micr

RE: kernel panics with 4.14.X versions

2018-04-20 Thread Dexuan Cui
> From: Jan Kara <j...@suse.cz> > Sent: Friday, April 20, 2018 03:22 > On Thu 19-04-18 21:37:25, Dexuan Cui wrote: > > > From: Jan Kara > > > Sent: Thursday, April 19, 2018 13:23 > > > Good news guys, Robert has just spotted a bug which looks like wh

RE: kernel panics with 4.14.X versions

2018-04-19 Thread Dexuan Cui
> From: Jan Kara > Sent: Thursday, April 19, 2018 13:23 > Good news guys, Robert has just spotted a bug which looks like what I'd > expect can cause your lockups / crashes. I've merged his patch to my tree > and will push it to Linus for -rc3 so eventually it should land in > appropriate stable

RE: kernel panics with 4.14.X versions

2018-04-17 Thread Dexuan Cui
> From: Greg KH <g...@kroah.com> > Sent: Tuesday, April 17, 2018 03:34 > On Mon, Apr 16, 2018 at 09:10:35PM +0000, Dexuan Cui wrote: > > > From: Jan Kara <j...@suse.cz> > > > Sent: Monday, April 16, 2018 07:41 > > > ... > > > How easily can

RE: kernel panics with 4.14.X versions

2018-04-16 Thread Dexuan Cui
> From: Jan Kara > Sent: Monday, April 16, 2018 07:41 > ... > How easily can you hit this? Are you able to run debug kernels / inspect > crash dumps when the issue occurs? Also testing with the latest mainline > kernel (4.16) would be welcome whether this isn't just an issue with

RE: Any standard kernel API to dynamically allocate/free per-cpu vectors on x86?

2018-04-05 Thread Dexuan Cui
> From: Thomas Gleixner > > Can you please give a little more guidance? e.g. is there any similar > > driver, > > any pointer to the required APIs, etc. > > Your quick pointer would help a lot! > > > > BTW, so far, Hyper-V doesn't support CPU hotplug, but it supports dynamic > > CPU

RE: Any standard kernel API to dynamically allocate/free per-cpu vectors on x86?

2018-04-04 Thread Dexuan Cui
> From: Thomas Gleixner > > I'm wondering if there is such a standard kernel API on x86. > > As I skimmed through the code, I haven't found it yet, if any. > > > We don't have a simple way to do such allocations because they involve IDT > entry manipulation. Hi tglx, Thanks for the quick detailed

Any standard kernel API to dynamically allocate/free per-cpu vectors on x86?

2018-04-04 Thread Dexuan Cui
Hi, Recently, two Hyper-V specific vectors were introduced in arch/x86/include/asm/irq_vectors.h: #if IS_ENABLED(CONFIG_HYPERV) #define HYPERV_REENLIGHTENMENT_VECTOR 0xee #define HYPERV_STIMER0_VECTOR 0xed #endif What if we need more such vectors on Hyper-V? This static global

RE: [PATCH v4 3/4] PCI: hv: Remove hbus->enum_sem

2018-03-16 Thread Dexuan Cui
> From: Lorenzo Pieralisi > Sent: Friday, March 16, 2018 11:32 > ... > > OK, patch series reworked and queued in my pci/hv branch please have > a look and let me know if that looks OK for you, I won't ask Bjorn > to move it into -next till you give me the go-ahead. >

RE: [PATCH v4 3/4] PCI: hv: Remove hbus->enum_sem

2018-03-16 Thread Dexuan Cui
> From: Lorenzo Pieralisi > Sent: Friday, March 16, 2018 03:54 > ... > Dexuan, > while applying/updating these patches I notice this one may be squashed > into: https://patchwork.ozlabs.org/patch/886266/ > > since they logically belong in the same patch. Are you OK

RE: [PATCH v4 1/2] PCI: hv: Serialize the present and eject work items

2018-03-15 Thread Dexuan Cui
> From: Dexuan Cui > > From: Lorenzo Pieralisi <lorenzo.pieral...@arm.com> > > I need to know either what commit you are fixing (ie Fixes: tag - which > > is preferrable) or you tell me which kernel versions we are targeting > > for the stable backport. > > L

RE: [PATCH v4 1/2] PCI: hv: Serialize the present and eject work items

2018-03-15 Thread Dexuan Cui
> From: Lorenzo Pieralisi <lorenzo.pieral...@arm.com> > Sent: Thursday, March 15, 2018 10:02 > On Thu, Mar 15, 2018 at 02:20:53PM +0000, Dexuan Cui wrote: > > When we hot-remove the device, we first receive a PCI_EJECT message and > > then receive a PCI_BUS_REL

[PATCH v4 2/4] PCI: hv: Remove the bogus test in hv_eject_device_work()

2018-03-15 Thread Dexuan Cui
When we're in the function, hpdev->state must be hv_pcichild_ejecting: see hv_pci_eject_device(). Signed-off-by: Dexuan Cui <de...@microsoft.com> Reviewed-by: Michael Kelley <mikel...@microsoft.com> Acked-by: Haiyang Zhang <haiya...@microsoft.com> Cc: Vitaly Kuznetsov <

[PATCH v4 3/4] PCI: hv: Remove hbus->enum_sem

2018-03-15 Thread Dexuan Cui
Since we serialize the present/eject work items now, we don't need the semaphore any more. Signed-off-by: Dexuan Cui <de...@microsoft.com> Reviewed-by: Michael Kelley <mikel...@microsoft.com> Acked-by: Haiyang Zhang <haiya...@microsoft.com> Cc: Vitaly Kuznetsov <vkuzn...

[PATCH v4 4/4] PCI: hv: Only queue a new work in hv_pci_devices_present() if necessary

2018-03-15 Thread Dexuan Cui
If there is a pending work, we just need to add the new dr into the dr_list. Signed-off-by: Dexuan Cui <de...@microsoft.com> Reviewed-by: Michael Kelley <mikel...@microsoft.com> Acked-by: Haiyang Zhang <haiya...@microsoft.com> Cc: Vitaly Kuznetsov <vkuzn...@redhat.com>

[PATCH v4 1/4] PCI: hv: Fix a comment typo in _hv_pcifront_read_config()

2018-03-15 Thread Dexuan Cui
No functional change. Fixes: bdd74440d9e8 ("PCI: hv: Add explicit barriers to config space access") Signed-off-by: Dexuan Cui <de...@microsoft.com> Acked-by: Haiyang Zhang <haiya...@microsoft.com> Cc: Vitaly Kuznetsov <vkuzn...@redhat.com> Cc: Stephen Hemminger <s

[PATCH v4 2/2] PCI: hv: Fix 2 hang issues in hv_compose_msi_msg()

2018-03-15 Thread Dexuan Cui
"hbus->hdev->channel->target_cpu == smp_processor_id()" is true. Fixes: 4900be83602b ("x86/vector/msi: Switch to global reservation mode") Tested-by: Adrian Suhov <v-ads...@microsoft.com> Tested-by: Chris Valean <v-chv...@microsoft.com> Signed-off-by

[PATCH v4 0/4] PCI: hv: Add 4 cosmetic patches

2018-03-15 Thread Dexuan Cui
issues in changelog (I hope I have fixed all of them). Dexuan Cui (4): PCI: hv: Fix a comment typo in _hv_pcifront_read_config() PCI: hv: Remove the bogus test in hv_eject_device_work() PCI: hv: Remove hbus->enum_sem PCI: hv: Only queue a new work in hv_pci_devices_pres

[PATCH v4 1/2] PCI: hv: Serialize the present and eject work items

2018-03-15 Thread Dexuan Cui
ing list_del(>list_entry), causing general protection fault, because system_wq can run them concurrently. The patch eliminates the race condition. Tested-by: Adrian Suhov <v-ads...@microsoft.com> Tested-by: Chris Valean <v-chv...@microsoft.com> Signed-off-by: Dexuan Cui <de...@mi

[PATCH v4 0/2] PCI: hv: Fix some real issues

2018-03-15 Thread Dexuan Cui
anything this time. :-) Dexuan Cui (2): PCI: hv: Serialize the present and eject work items PCI: hv: Fix 2 hang issues in hv_compose_msi_msg() drivers/pci/host/pci-hyperv.c | 75 --- 1 file changed, 71 insertions(+), 4 deletions(-) -- 2.7.4

RE: [PATCH v3 6/6] PCI: hv: fix 2 hang issues in hv_compose_msi_msg()

2018-03-14 Thread Dexuan Cui
> From: Lorenzo Pieralisi <lorenzo.pieral...@arm.com> > Sent: Wednesday, March 14, 2018 04:50 > On Tue, Mar 13, 2018 at 06:23:39PM +0000, Dexuan Cui wrote: > > [...] > > > Hi Lorenzo, Bjorn, and all, > > Do you need more ACKs? Currently Michael and Haiyang

RE: [PATCH v3 6/6] PCI: hv: fix 2 hang issues in hv_compose_msi_msg()

2018-03-13 Thread Dexuan Cui
> From: Dexuan Cui > Sent: Wednesday, March 7, 2018 13:40 > To: Lorenzo Pieralisi <lorenzo.pieral...@arm.com> > Cc: bhelg...@google.com; linux-...@vger.kernel.org; KY Srinivasan > <k...@microsoft.com>; Stephen Hemminger <sthem...@microsoft.com>; > o...@

RE: [PATCH v3 6/6] PCI: hv: fix 2 hang issues in hv_compose_msi_msg()

2018-03-07 Thread Dexuan Cui
> From: Lorenzo Pieralisi <lorenzo.pieral...@arm.com> > Sent: Wednesday, March 7, 2018 04:35 > On Tue, Mar 06, 2018 at 06:21:56PM +0000, Dexuan Cui wrote: > > 1. With the patch "x86/vector/msi: Switch to global reservation mode" > > (4900be8360), the recen

[PATCH v3 2/6] PCI: hv: hv_eject_device_work(): remove the bogus test

2018-03-06 Thread Dexuan Cui
When we're in the function, hpdev->state must be hv_pcichild_ejecting: see hv_pci_eject_device(). Signed-off-by: Dexuan Cui <de...@microsoft.com> Cc: Vitaly Kuznetsov <vkuzn...@redhat.com> Cc: Jack Morgenstein <ja...@mellanox.com> Cc: sta...@vger.kernel.org Cc: Ste

[PATCH v3 0/6] some fixes to the pci-hyperv driver.

2018-03-06 Thread Dexuan Cui
by Michael Kelley. Dexuan Cui (6): PCI: hv: fix a comment typo in _hv_pcifront_read_config() PCI: hv: hv_eject_device_work(): remove the bogus test PCI: hv: serialize the present/eject work items PCI: hv: remove hbus->enum_sem PCI: hv: hv_pci_devices_present(): only queue a new work w

[PATCH v3 3/6] PCI: hv: serialize the present/eject work items

2018-03-06 Thread Dexuan Cui
ing list_del(>list_entry), causing general protection fault, because system_wq can run them concurrently. The patch eliminates the race condition. Signed-off-by: Dexuan Cui <de...@microsoft.com> Tested-by: Adrian Suhov <v-ads...@microsoft.com> Tested-by: Chris Valean <v-chv...@micr

[PATCH v3 5/6] PCI: hv: hv_pci_devices_present(): only queue a new work when necessary

2018-03-06 Thread Dexuan Cui
If there is a pending work, we just need to add the new dr into the dr_list. This is suggested by Michael Kelley. Signed-off-by: Dexuan Cui <de...@microsoft.com> Cc: Vitaly Kuznetsov <vkuzn...@redhat.com> Cc: Jack Morgenstein <ja...@mellanox.com> Cc: sta...@vger.kernel.org Cc:

[PATCH v3 1/6] PCI: hv: fix a comment typo in _hv_pcifront_read_config()

2018-03-06 Thread Dexuan Cui
No functional change. Signed-off-by: Dexuan Cui <de...@microsoft.com> Fixes: bdd74440d9e8 ("PCI: hv: Add explicit barriers to config space access") Cc: Vitaly Kuznetsov <vkuzn...@redhat.com> Cc: sta...@vger.kernel.org Cc: Stephen Hemminger <sthem...@microsoft.com

[PATCH v3 4/6] PCI: hv: remove hbus->enum_sem

2018-03-06 Thread Dexuan Cui
Since we serialize the present/eject work items now, we don't need the semaphore any more. This is suggested by Michael Kelley. Signed-off-by: Dexuan Cui <de...@microsoft.com> Cc: Vitaly Kuznetsov <vkuzn...@redhat.com> Cc: Jack Morgenstein <ja...@mellanox.com> Cc: sta...@

[PATCH v3 6/6] PCI: hv: fix 2 hang issues in hv_compose_msi_msg()

2018-03-06 Thread Dexuan Cui
PCI vendor ID. Note: actually the above issues also happen to a SMP VM, if "hbus->hdev->channel->target_cpu == smp_processor_id()" is true. Signed-off-by: Dexuan Cui <de...@microsoft.com> Tested-by: Adrian Suhov <v-ads...@microsoft.com> Tested-by: Chris Valean &l

RE: [PATCH v2 5/6] PCI: hv: hv_pci_devices_present(): only queue a new work when necessary

2018-03-05 Thread Dexuan Cui
> From: Michael Kelley (EOSG) > Sent: Monday, March 5, 2018 15:48 > > @@ -1756,11 +1757,23 @@ static void hv_pci_devices_present(struct > hv_pcibus_device > > *hbus, > > } > > > > spin_lock_irqsave(>device_list_lock, flags); > > + > > + /* > > +* If pending_dr is true, we have

[PATCH v2 1/6] PCI: hv: fix a comment typo in _hv_pcifront_read_config()

2018-03-05 Thread Dexuan Cui
No functional change. Signed-off-by: Dexuan Cui <de...@microsoft.com> Fixes: bdd74440d9e8 ("PCI: hv: Add explicit barriers to config space access") Cc: Vitaly Kuznetsov <vkuzn...@redhat.com> Cc: sta...@vger.kernel.org Cc: Stephen Hemminger <sthem...@microsoft.com

[PATCH v2 3/6] PCI: hv: serialize the present/eject work items

2018-03-05 Thread Dexuan Cui
ing list_del(>list_entry), causing general protection fault, because system_wq can run them concurrently. The patch eliminates the race condition. Signed-off-by: Dexuan Cui <de...@microsoft.com> Tested-by: Adrian Suhov <v-ads...@microsoft.com> Tested-by: Chris Valean <v-chv...@micr

[PATCH v2 5/6] PCI: hv: hv_pci_devices_present(): only queue a new work when necessary

2018-03-05 Thread Dexuan Cui
If there is a pending work, we just need to add the new dr into the dr_list. This is suggested by Michael Kelley. Signed-off-by: Dexuan Cui <de...@microsoft.com> Cc: Vitaly Kuznetsov <vkuzn...@redhat.com> Cc: Jack Morgenstein <ja...@mellanox.com> Cc: sta...@vger.kernel.org Cc:

[PATCH v2 4/6] PCI: hv: remove hbus->enum_sem

2018-03-05 Thread Dexuan Cui
Since we serialize the present/eject work items now, we don't need the semaphore any more. This is suggested by Michael Kelley. Signed-off-by: Dexuan Cui <de...@microsoft.com> Cc: Vitaly Kuznetsov <vkuzn...@redhat.com> Cc: Jack Morgenstein <ja...@mellanox.com> Cc: sta...@

[PATCH v2 6/6] PCI: hv: fix 2 hang issues in hv_compose_msi_msg()

2018-03-05 Thread Dexuan Cui
PCI vendor ID. Note: actually the above issues also happen to a SMP VM, if "hbus->hdev->channel->target_cpu == smp_processor_id()" is true. Signed-off-by: Dexuan Cui <de...@microsoft.com> Tested-by: Adrian Suhov <v-ads...@microsoft.com> Tested-by: Chris Valean &l

[PATCH v2 0/6] some fixes to the pci-hyperv driver.

2018-03-05 Thread Dexuan Cui
Changes since v1 are: Patch 1, 6: no change since v1. Patch 2,4,5: I added these new patches, as suggested by Michael Kelley. Patch 3: Removed the unnecessary drain_workqueue(), as suggested by Michael Kelley. Dexuan Cui (6): PCI: hv: fix a comment typo in _hv_pcifront_read_config() PCI

[PATCH v2 2/6] PCI: hv: hv_eject_device_work(): remove the bogus test

2018-03-05 Thread Dexuan Cui
When we're in the function, hpdev->state must be hv_pcichild_ejecting: see hv_pci_eject_device(). Signed-off-by: Dexuan Cui <de...@microsoft.com> Cc: Vitaly Kuznetsov <vkuzn...@redhat.com> Cc: Jack Morgenstein <ja...@mellanox.com> Cc: sta...@vger.kernel.org Cc: Ste

RE: [PATCH 2/3] PCI: hv: serialize the present/eject work items

2018-03-04 Thread Dexuan Cui
> From: Michael Kelley (EOSG) > Sent: Saturday, March 3, 2018 08:10 > > From: linux-kernel-ow...@vger.kernel.org ow...@vger.kernel.org> On Behalf Of Dexuan Cui > > Sent: Friday, March 2, 2018 4:21 PM > > When we hot-remove the device, we first receive a PCI_EJECT m

[PATCH] Drivers: hv: vmbus: respect what we get from hv_get_synint_state()

2018-03-02 Thread Dexuan Cui
I didn't really hit a bug, but just happened to notice the redundant line. Signed-off-by: Dexuan Cui <de...@microsoft.com> Cc: Stephen Hemminger <sthem...@microsoft.com> Cc: K. Y. Srinivasan <k...@microsoft.com> Cc: sta...@vger.kernel.org --- drivers/hv/hv.c | 1 - 1 file c

[PATCH] Drivers: hv: vmbus: do not mark HV_PCIE as perf_device

2018-03-02 Thread Dexuan Cui
driver's hv_compose_msi_msg(). Signed-off-by: Dexuan Cui <de...@microsoft.com> Cc: sta...@vger.kernel.org Cc: Stephen Hemminger <sthem...@microsoft.com> Cc: K. Y. Srinivasan <k...@microsoft.com> --- drivers/hv/channel_mgmt.c | 2 +- 1 file changed, 1 insertion(+), 1 delet

[PATCH 3/3] PCI: hv: fix 2 hang issues in hv_compose_msi_msg()

2018-03-02 Thread Dexuan Cui
PCI vendor ID. Note: actually the above issues also happen to a SMP VM, if "hbus->hdev->channel->target_cpu == smp_processor_id()" is true. Signed-off-by: Dexuan Cui <de...@microsoft.com> Tested-by: Adrian Suhov <v-ads...@microsoft.com> Tested-by: Chris Valean &l

[PATCH 2/3] PCI: hv: serialize the present/eject work items

2018-03-02 Thread Dexuan Cui
ing list_del(>list_entry), causing general protection fault, because system_wq can run them concurrently. The patch eliminates the race condition. Signed-off-by: Dexuan Cui <de...@microsoft.com> Tested-by: Adrian Suhov <v-ads...@microsoft.com> Tested-by: Chris Valean <v-chv...@micr

[PATCH 1/3] PCI: hv: fix a comment typo in _hv_pcifront_read_config()

2018-03-02 Thread Dexuan Cui
No functional change. Signed-off-by: Dexuan Cui <de...@microsoft.com> Fixes: bdd74440d9e8 ("PCI: hv: Add explicit barriers to config space access") Cc: Vitaly Kuznetsov <vkuzn...@redhat.com> Cc: sta...@vger.kernel.org Cc: Stephen Hemminger <sthem...@microsoft.com

Any known soft lockup issue with vfs_write()->fsnotify()?

2018-03-02 Thread Dexuan Cui
Hi, Recently people are getting a soft lock issue with vfs_write()->fsnotify(). The detailed calltrace is available at: https://github.com/coreos/bugs/issues/2356 https://github.com/coreos/bugs/issues/2364 The kernel versions showing up the issue are: 4.14.11-coreos 4.14.19-coreos 4.13.0-1009

RE: tip/master falls off NOP cliff with KPTI under KVM

2018-01-25 Thread Dexuan Cui
> From: David Woodhouse [mailto:dw...@infradead.org] > Sent: Wednesday, January 24, 2018 23:53 > On Wed, 2018-01-24 at 16:53 -0800, Dexuan-Linux Cui wrote: > > On Wed, Jan 10, 2018 at 2:53 PM, Woodhouse, David > wrote: > > > > > > On Thu, 2018-01-11 at 01:34 +0300, Alexey

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

2017-12-28 Thread Dexuan Cui
> From: Thomas Gleixner [mailto:t...@linutronix.de] > Sent: Thursday, December 28, 2017 03:03 > > > On Wed, Dec 20, 2017 at 02:12:05AM +0000, Dexuan Cui wrote: > > > > For Linux VM running on Hyper-V, we did get "spurious APIC interrupt > > > throug

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

2017-12-22 Thread Dexuan Cui
> 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

2017-12-22 Thread Dexuan Cui
> 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

2017-12-11 Thread Dexuan Cui
> 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

2017-12-11 Thread Dexuan Cui
; 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 0/4] hv_balloon: fixes for num_pages_onlined accounting and misc improvements

2017-11-29 Thread Dexuan Cui
> -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

[PATCH] vmbus: unregister device_obj->channels_kset

2017-11-12 Thread Dexuan Cui
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.

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

2017-11-07 Thread Dexuan Cui
> 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

2017-11-01 Thread Dexuan Cui
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 net] hv_sock: add locking in the open/close/release code paths

2017-10-18 Thread Dexuan Cui
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>

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

2017-10-17 Thread Dexuan Cui
> 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

2017-10-13 Thread Dexuan Cui
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()

2017-10-09 Thread Dexuan Cui
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

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

2017-09-06 Thread Dexuan Cui
> 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

2017-09-02 Thread Dexuan Cui
> 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

2017-08-28 Thread Dexuan Cui
> 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)

2017-08-28 Thread Dexuan Cui
> 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

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

2017-08-25 Thread Dexuan Cui
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

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

2017-08-24 Thread Dexuan Cui
> 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)

2017-08-22 Thread Dexuan Cui
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

  1   2   3   4   5   6   >