> 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 can
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 D
> 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 t
> 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 tre
> 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
> 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 th
> 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 bound
> 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
> 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
> 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 se
> 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 config/logs
> 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 unclear
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/AB
> 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
> 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 Documenta
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
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
---
> 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 fi
> 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
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
--
> 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 do
> 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/
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 "ndc
> 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);
> > > + mu
> 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"
> f
> 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:
> 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 (si
> 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
scind 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 Hemmin
> 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
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 th
c: 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/hype
> 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.
>
> 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
> 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
Srinivasan
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
> 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
> 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 ("D
tch should be applied to all the existing 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.
> 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
> 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
> 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
> &
> 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 ther
tch should be applied to all the existing 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:
> 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
> 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: v4.19
> 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
> 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):
>
> 5f4b04528b5f
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
https://bugs.launchpad.net/ubuntu/+source/li
> 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:
> 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
> 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.oper
> 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 '
> 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,
> > + in_
> 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)
> > >
> > > out->body.kvp_ip_val.dhcp_enable
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/h
irq_save()/restore()
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: H
> 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
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.
ix the 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. S
d.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
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
> 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
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 (&quo
> 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
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:
> 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 necessa
> 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 details,
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 shou
> From: Stephen Hemminger
> Sent: Tuesday, May 8, 2018 15:45
> On Tue, 8 May 2018 22:26:21 +
> Dexuan Cui wrote:
>
> > @@ -63,6 +63,9 @@ static __u32 vmbus_get_next_version(__u32
> current_version)
> > case (VERSION_WIN10):
> > ret
t-returned 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
Cc: Stephen
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:
> From: Jan Kara
> 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 what I'd
> >
> 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 tre
> From: Greg KH
> Sent: Tuesday, April 17, 2018 03:34
> On Mon, Apr 16, 2018 at 09:10:35PM +0000, Dexuan Cui wrote:
> > > From: Jan Kara
> > > Sent: Monday, April 16, 2018 07:41
> > > ...
> > > How easily can you hit this? Are you able to run debug
> 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 the
> backport of
> 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 online/offline
> 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
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 reserva
> 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.
>
> Lorenzo
Yes, it looks goo
> 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 with me doing
> that ? Is my re
> From: Dexuan Cui
> > From: Lorenzo Pieralisi
> > 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.
> > Lorenzo
>
> Sorry. Here I
> From: Lorenzo Pieralisi
> 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_RELATIONS message with bus_rel->device_c
When we're in the function, hpdev->state must be hv_pcichild_ejecting:
see hv_pci_eject_device().
Signed-off-by: Dexuan Cui
Reviewed-by: Michael Kelley
Acked-by: Haiyang Zhang
Cc: Vitaly Kuznetsov
Cc: Jack Morgenstein
Cc: Stephen Hemminger
Cc: K. Y. Srinivasan
---
drivers/pci/
Since we serialize the present/eject work items now, we don't need the
semaphore any more.
Signed-off-by: Dexuan Cui
Reviewed-by: Michael Kelley
Acked-by: Haiyang Zhang
Cc: Vitaly Kuznetsov
Cc: Jack Morgenstein
Cc: Stephen Hemminger
Cc: K. Y. Srinivasan
---
drivers/pci/host/pci-hyp
If there is a pending work, we just need to add the new dr into
the dr_list.
Signed-off-by: Dexuan Cui
Reviewed-by: Michael Kelley
Acked-by: Haiyang Zhang
Cc: Vitaly Kuznetsov
Cc: Jack Morgenstein
Cc: Stephen Hemminger
Cc: K. Y. Srinivasan
---
drivers/pci/host/pci-hyperv.c | 15
No functional change.
Fixes: bdd74440d9e8 ("PCI: hv: Add explicit barriers to config space access")
Signed-off-by: Dexuan Cui
Acked-by: Haiyang Zhang
Cc: Vitaly Kuznetsov
Cc: Stephen Hemminger
Cc: K. Y. Srinivasan
---
drivers/pci/host/pci-hyperv.c | 2 +-
1 file changed, 1 inser
MP VM, if
"hbus->hdev->channel->target_cpu == smp_processor_id()" is true.
Fixes: 4900be83602b ("x86/vector/msi: Switch to global reservation mode")
Tested-by: Adrian Suhov
Tested-by: Chris Valean
Signed-off-by: Dexuan Cui
Reviewed-by: Michael Kelley
Acked-by: Haiyan
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_present()
ing
list_del(&hpdev->list_entry), causing general protection fault, because
system_wq can run them concurrently.
The patch eliminates the race condition.
Tested-by: Adrian Suhov
Tested-by: Chris Valean
Signed-off-by: Dexuan Cui
Reviewed-by: Michael Kelley
Acked-by: Haiyang Zhan
omit
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
> From: Lorenzo Pieralisi
> 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 reviewed and ack'd
> >
> From: Dexuan Cui
> Sent: Wednesday, March 7, 2018 13:40
> To: Lorenzo Pieralisi
> Cc: bhelg...@google.com; linux-...@vger.kernel.org; KY Srinivasan
> ; Stephen Hemminger ;
> o...@aepfle.de; a...@canonical.com; jasow...@redhat.com; linux-
> ker...@vger.ker
> From: Lorenzo Pieralisi
> 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 recent v4.15 and newer kernels always hang
When we're in the function, hpdev->state must be hv_pcichild_ejecting:
see hv_pci_eject_device().
Signed-off-by: Dexuan Cui
Cc: Vitaly Kuznetsov
Cc: Jack Morgenstein
Cc: sta...@vger.kernel.org
Cc: Stephen Hemminger
Cc: K. Y. Srinivasan
Cc: Michael Kelley (EOSG)
---
drivers/pci/
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
ing
list_del(&hpdev->list_entry), causing general protection fault, because
system_wq can run them concurrently.
The patch eliminates the race condition.
Signed-off-by: Dexuan Cui
Tested-by: Adrian Suhov
Tested-by: Chris Valean
Cc: Vitaly Kuznetsov
Cc: Jack Morgenstein
Cc: sta...@vger.ker
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
Cc: Vitaly Kuznetsov
Cc: Jack Morgenstein
Cc: sta...@vger.kernel.org
Cc: Stephen Hemminger
Cc: K. Y. Srinivasan
Cc: Michael Kelley (EOSG)
---
drivers
No functional change.
Signed-off-by: Dexuan Cui
Fixes: bdd74440d9e8 ("PCI: hv: Add explicit barriers to config space access")
Cc: Vitaly Kuznetsov
Cc: sta...@vger.kernel.org
Cc: Stephen Hemminger
Cc: K. Y. Srinivasan
---
drivers/pci/host/pci-hyperv.c | 2 +-
1 file changed, 1 inser
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
Cc: Vitaly Kuznetsov
Cc: Jack Morgenstein
Cc: sta...@vger.kernel.org
Cc: Stephen Hemminger
Cc: K. Y. Srinivasan
Cc: Michael Kelley
301 - 400 of 842 matches
Mail list logo