RE: [PATCH] libnvdimm/dimm: Add a no-BLK quirk based on NVDIMM family

> From: Dan Williams > Sent: Sunday, February 3, 2019 11:14 AM > > ... > > As I understand, the essence of the issue is: Hyper-V emulates the > > label mechanism (i.e. it supports _LSI and LSR), but doesn't do it > > right (i.e. it doesn't support _LSW). > > > > To manage the namespaces, Linux

RE: [PATCH] acpi/nfit: Require opt-in for read-only label configurations

LSW method, disable all label access > methods. Provide a 'force_labels' module parameter to allow read-only > label operation. > > Fixes: 11189c1089da ("acpi/nfit: Fix command-supported detection") > Reported-by: Dexuan Cui > Signed-off-by: Dan Williams Hi Dan, Thanks

RE: [PATCH] libnvdimm/dimm: Add a no-BLK quirk based on NVDIMM family

> From: Dan Williams > Sent: Sunday, February 3, 2019 9:49 AM > > ... > > It looks the namespace created by Ubuntu 19.04 (4.18) is incompatible with > > the libnvdimm-pending branch + this patch. > > This is correct, the configuration switched from label-less by default > to labeled. Thanks for

RE: [PATCH] libnvdimm/dimm: Add a no-BLK quirk based on NVDIMM family

> From: kbuild test robot > Sent: Sunday, February 3, 2019 6:38 AM > ... > Hi Dan, > > I love your patch! Yet something to improve: > > [auto build test ERROR on linux-nvdimm/libnvdimm-for-next] > [also build test ERROR on v5.0-rc4 next-20190201] > [if your patch is applied to the wrong git

RE: [PATCH] libnvdimm/dimm: Add a no-BLK quirk based on NVDIMM family

> From: kbuild test robot > Sent: Sunday, February 3, 2019 6:32 AM > To: Dan Williams > Cc: kbuild-...@01.org; linux-nvd...@lists.01.org; Dexuan Cui > ; linux-kernel@vger.kernel.org > Subject: Re: [PATCH] libnvdimm/dimm: Add a no-BLK quirk based on NVDIMM > family > &g

RE: [PATCH] libnvdimm/dimm: Add a no-BLK quirk based on NVDIMM family

> From: Dan Williams > Sent: Saturday, February 2, 2019 5:13 PM > ... > As Dexuan reports the NVDIMM_FAMILY_HYPERV platform is incompatible with > the existing Linux namespace implementation because it uses > NSLABEL_FLAG_LOCAL for x1-width PMEM interleave sets. Quirk it as an > platform / DIMM

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

> 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

> 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

> 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

> 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

> 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

> 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

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

> 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-de...@linuxdriverproject.org; Rafael J. Wysocki > ; linux-kernel@vger.kernel.org; Michae

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

> 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

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

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

> 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

RE: [PATCH] nfit: Fix nfit_intel_shutdown_status() command submission

> From: Dan Williams > Sent: Monday, January 28, 2019 9:22 PM > To: linux-nvd...@lists.01.org > Cc: sta...@vger.kernel.org; Dexuan Cui ; > linux-kernel@vger.kernel.org > Subject: [PATCH] nfit: Fix nfit_intel_shutdown_status() command submission > > The implementation i

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

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

> 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

> 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

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

> 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

> 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

> 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-kernel@vger.kernel.org > Subject:

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

> 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

> 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

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

RE: Recent VFS/LSM patches cause Kernel panic - not syncing: Can't create rootfs

> From: Dexuan Cui > Sent: Wednesday, December 19, 2018 8:30 PM > > Hi, > We started to see a "Can't create rootfs" panic with linux-next's > next-20181218 and next-20181219. Note: next-20181217 is good. > > Our test team found the first bad commit by git-bisec

Recent VFS/LSM patches cause Kernel panic - not syncing: Can't create rootfs

Hi, We started to see a "Can't create rootfs" panic with linux-next's next-20181218 and next-20181219. Note: next-20181217 is good. Our test team found the first bad commit by git-bisect: 013c7af575e5 ("vfs: Implement a filesystem superblock creation/configuration context") I had a look and I

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

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

> 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

> 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

> 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

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: linux-next: manual merge of the char-misc tree with the char-misc.current tree

> From: Greg KH > Sent: Monday, December 10, 2018 1:47 AM > On Tue, Dec 04, 2018 at 08:46:41AM +0000, Dexuan Cui wrote: > > > From: Greg KH > > > Sent: Monday, December 3, 2018 11:43 PM > > > On Tue, Dec 04, 2018 at 03:35:13PM +1100, St

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

> 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

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

> 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

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

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

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

> 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

> 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

> 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

> 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

> 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

> 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

> 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

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

> 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

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

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

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

> 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 2/2] Drivers: hv: vmbus: offload the handling of channels to two workqueues

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

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

> 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

> 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: [PATCH V2 3/5] Drivers: hv: kvp: Fix the recent regression caused by incorrect clean-up

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

> 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

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

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

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

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

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

> 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

> 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

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

> 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

> 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 V2 3/5] Drivers: hv: kvp: Fix the recent regression caused by incorrect clean-up

> 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

> 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 5/5] Tools: hv: kvp: Fix a warning of buffer overflow with gcc 8.0.1

> 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

> 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

> 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

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

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

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

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] x86/hyperv: suppress "PCI: Fatal: No config space access function found"

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

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

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

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

> 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

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

> From: Lorenzo Pieralisi > 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 host, and after that the host won't

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

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: Do not wait forever on a device that has disappeared

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 Cc: Stephen Hemminger Cc: K. Y. Srinivasan

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

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

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

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 Cc: Cc: Stephen Hemminger Cc: K. Y. Srin

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

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>

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

S 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

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

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:

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

Commit-ID: 5596fe34495cf0f645f417eb928ef224df3e3cb4 Gitweb: https://git.kernel.org/tip/5596fe34495cf0f645f417eb928ef224df3e3cb4 Author: Dexuan Cui AuthorDate: Tue, 15 May 2018 19:52:50 + Committer: Thomas Gleixner CommitDate: Tue, 15 May 2018 22:45:54 +0200 tick/broadcast: Use

RE: for_each_cpu() is buggy for UP kernel?

> 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

RE: for_each_cpu() is buggy for UP kernel?

> From: Linus Torvalds > Sent: Tuesday, May 15, 2018 10:22 > To: Dexuan Cui > > On Mon, May 14, 2018 at 8:02 PM Dexuan Cui wrote: > > > If you're OK with the below fix (not tested yet), I'll submit a patch for > > it: > > > --- a/kernel/time/tick

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

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

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

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 Cc: sta...@vger.kernel.org --- Some part of the changelog and comments are copied from Thomas Gleixner's 115ef3b7e61a ("wat

RE: for_each_cpu() is buggy for UP kernel?

> 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

RE: for_each_cpu() is buggy for UP kernel?

> From: Linus Torvalds > Sent: Sunday, May 13, 2018 11:22 > On Tue, May 8, 2018 at 11:24 PM Dexuan Cui wrote: > > > Should we fix the for_each_cpu() in include/linux/cpumask.h for UP? > > As Thomas points out, this has come up before. > > One of the issues is h

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

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

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

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 Cc: Stephen Hemminger Cc: K. Y. Srinivasan --- Thanks Stephen Hemminger for pointing this out! So far, ae20b254306a ("Drivers: hv: vmbu

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

> 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

> From: Stephen Hemminger > Sent: Monday, May 14, 2018 11:18 > To: Dexuan Cui > > > ... > > > Hate to pick o the details, but buffer is void * so cast is not necessary > > > here. > > > > Yes, it's unnecessary in C, though it's necessary in C++.

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

> 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

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

> 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 vmbus_channel_message_header *)buffer; > > Hate to pick o the

for_each_cpu() is buggy for UP kernel?

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

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