* [PATCH 0/2] Drivers: hv: Move Hyper-V clock/timer code to separate clocksource driver
From: Michael Kelley @ 2019-03-12 21:42 UTC (permalink / raw)
To: will.deacon@arm.com, marc.zyngier@arm.com,
linux-arm-kernel@lists.infradead.org, gregkh@linuxfoundation.org,
linux-kernel@vger.kernel.org, linux-hyperv@vger.kernel.org,
olaf@aepfle.de, apw@canonical.com, vkuznets, jasowang@redhat.com,
marcelo.cerri@canonical.com, Sunil Muthuswamy, KY Srinivasan
Cc: Michael Kelley, catalin.marinas@arm.com, mark.rutland@arm.com
This patch series moves Hyper-V clock/timer code to a separate Hyper-V
clocksource driver. Previously, Hyper-V clock/timer code and data
structures were mixed in with other Hyper-V code in the ISA independent
drivers/hv code as well as in arch dependent code. The new Hyper-V
clocksource driver is ISA independent, with a just few dependencies on
arch specific functions. The patch series does not change any behavior
or functionality -- it only reorganizes the existing code and fixes up
the linkages. A few places outside of Hyper-V code are fixed up to use
the new #include file structure.
This restructuring is in response to Marc Zyngier's review comments
on supporting Hyper-V running on ARM64, and is a good idea in general.
It increases the amount of code shared between the x86 and ARM64
architectures, and reduces the size of the new code for supporting
Hyper-V on ARM64. A new version of the Hyper-V on ARM64 patches will
follow once this clocksource restructuring is accepted.
The code is currently diff'ed against Linux 5.0. I'll rebase
to linux-next once 5.1-rc1 is available.
Michael Kelley (2):
Drivers: hv: Move Hyper-V clockevents code to new clocksource driver
Drivers: hv: Move Hyper-V clocksource code to new clocksource driver
MAINTAINERS | 2 +
arch/x86/entry/vdso/vclock_gettime.c | 1 +
arch/x86/entry/vdso/vma.c | 2 +-
arch/x86/hyperv/hv_init.c | 91 +---------
arch/x86/include/asm/hyperv-tlfs.h | 6 +
arch/x86/include/asm/mshyperv.h | 80 ++-------
arch/x86/kernel/cpu/mshyperv.c | 2 +
arch/x86/kvm/x86.c | 1 +
drivers/clocksource/Makefile | 1 +
drivers/clocksource/hyperv_syntimer.c | 328 ++++++++++++++++++++++++++++++++++
drivers/hv/hv.c | 154 ----------------
drivers/hv/hyperv_vmbus.h | 3 -
drivers/hv/vmbus_drv.c | 39 ++--
include/clocksource/hyperv_syntimer.h | 104 +++++++++++
14 files changed, 482 insertions(+), 332 deletions(-)
create mode 100644 drivers/clocksource/hyperv_syntimer.c
create mode 100644 include/clocksource/hyperv_syntimer.h
--
1.8.3.1
^ permalink raw reply
* [PATCH v2] hv_netvsc: fix a possible NULL pointer dereference in netvsc_get_ethtool_stats()
From: Kangjie Lu @ 2019-03-12 5:01 UTC (permalink / raw)
To: kjlu
Cc: pakki001, K. Y. Srinivasan, Haiyang Zhang, Stephen Hemminger,
Sasha Levin, David S. Miller, linux-hyperv, netdev, linux-kernel
In case kvmalloc_array fails, we should stop using it to avoid
NULL pointer dereference.
Signed-off-by: Kangjie Lu <kjlu@umn.edu>
---
drivers/net/hyperv/netvsc_drv.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/net/hyperv/netvsc_drv.c b/drivers/net/hyperv/netvsc_drv.c
index cf4897043e83..4b3a03029fe8 100644
--- a/drivers/net/hyperv/netvsc_drv.c
+++ b/drivers/net/hyperv/netvsc_drv.c
@@ -1426,6 +1426,9 @@ static void netvsc_get_ethtool_stats(struct net_device *dev,
pcpu_sum = kvmalloc_array(num_possible_cpus(),
sizeof(struct netvsc_ethtool_pcpu_stats),
GFP_KERNEL);
+ if (!pcpu_sum)
+ return;
+
netvsc_get_pcpu_stats(dev, pcpu_sum);
for_each_present_cpu(cpu) {
struct netvsc_ethtool_pcpu_stats *this_sum = &pcpu_sum[cpu];
--
2.17.1
^ permalink raw reply related
* Re: [PATCH v5] Drivers: hv: vmbus: Expose monitor data only when monitor pages are used
From: Kimberly Brown @ 2019-03-12 0:04 UTC (permalink / raw)
To: Greg KH
Cc: Michael Kelley, Long Li, Sasha Levin, Stephen Hemminger,
Dexuan Cui, K. Y. Srinivasan, Haiyang Zhang, linux-hyperv,
linux-kernel
In-Reply-To: <20190309072135.GG3882@kroah.com>
On Sat, Mar 09, 2019 at 08:21:35AM +0100, Greg KH wrote:
> On Fri, Mar 08, 2019 at 05:46:11PM -0500, Kimberly Brown wrote:
> > static struct kobj_type vmbus_chan_ktype = {
> > .sysfs_ops = &vmbus_chan_sysfs_ops,
> > .release = vmbus_chan_release,
> > - .default_attrs = vmbus_chan_attrs,
>
> As discussed on IRC, a kobj_type needs to get an attribute group one of
> these days, not just a attribute list :)
>
> So thanks for persisting with this, sorry for the earlier review
> comments, you were totally right about this, nice work.
>
> Minor review comments below:
>
> > };
> >
> > /*
> > @@ -1571,11 +1624,34 @@ int vmbus_add_channel_kobj(struct hv_device *dev, struct vmbus_channel *channel)
> > if (ret)
> > return ret;
> >
> > + ret = sysfs_create_group(kobj, &vmbus_chan_group);
> > + channel->sysfs_group_ready = !ret;
>
> Why do you need this flag?
>
I added this flag to prevent sysfs_remove_group() from being called if
sysfs_create_group() or the earlier call to kobject_init_and_add()
failed. However, it looks like that would just lead to WARN() being
called, which seems appropriate. I'll remove this flag.
> > +
> > + if (ret) {
> > + /*
> > + * If an error is returned to the calling functions, those
> > + * functions will call kobject_put() on the channel kobject,
> > + * which will cleanup the empty channel directory created by
> > + * kobject_init_and_add().
>
> Why is this comment needed?
>
Another reviewer asked why the empty directory created by
kobject_init_and_add() isn't removed here when sysfs_create_group()
fails. We decided that a comment would help clear up any future
confusion.
> > + */
> > + pr_err("Unable to set up channel sysfs files\n");
>
> dev_err() to show who had the problem with the files?
>
Yes, good point. I'll change this.
> > + return ret;
> > + }
> > +
> > kobject_uevent(kobj, KOBJ_ADD);
> >
> > return 0;
> > }
> >
> > +/*
> > + * vmbus_remove_channel_attr_group - remove the channel's attribute group
> > + */
> > +void vmbus_remove_channel_attr_group(struct vmbus_channel *channel)
> > +{
> > + if (channel->sysfs_group_ready)
> > + sysfs_remove_group(&channel->kobj, &vmbus_chan_group);
>
> You should be able to just always remove these, no need for a flag to
> say you have created them or not, right?
>
> thanks,
>
> greg k-h
^ permalink raw reply
* RE: [PATCH] net: hyperv: fix a NULL pointer dereference
From: Haiyang Zhang @ 2019-03-11 19:49 UTC (permalink / raw)
To: Haiyang Zhang, Kangjie Lu
Cc: pakki001@umn.edu, KY Srinivasan, Stephen Hemminger, Sasha Levin,
David S. Miller, linux-hyperv@vger.kernel.org,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <DM5PR2101MB0725705F1CDDD3D1631CD509CA480@DM5PR2101MB0725.namprd21.prod.outlook.com>
> -----Original Message-----
> From: linux-hyperv-owner@vger.kernel.org <linux-hyperv-
> owner@vger.kernel.org> On Behalf Of Haiyang Zhang
> Sent: Monday, March 11, 2019 3:47 PM
> To: Kangjie Lu <kjlu@umn.edu>
> Cc: pakki001@umn.edu; KY Srinivasan <kys@microsoft.com>; Stephen
> Hemminger <sthemmin@microsoft.com>; Sasha Levin <sashal@kernel.org>;
> David S. Miller <davem@davemloft.net>; linux-hyperv@vger.kernel.org;
> netdev@vger.kernel.org; linux-kernel@vger.kernel.org
> Subject: RE: [PATCH] net: hyperv: fix a NULL pointer dereference
>
>
>
> > -----Original Message-----
> > From: Kangjie Lu <kjlu@umn.edu>
> > Sent: Monday, March 11, 2019 3:17 AM
> > To: kjlu@umn.edu
> > Cc: pakki001@umn.edu; KY Srinivasan <kys@microsoft.com>; Haiyang Zhang
> > <haiyangz@microsoft.com>; Stephen Hemminger
> <sthemmin@microsoft.com>;
> > Sasha Levin <sashal@kernel.org>; David S. Miller
> > <davem@davemloft.net>; linux-hyperv@vger.kernel.org;
> > netdev@vger.kernel.org; linux- kernel@vger.kernel.org
> > Subject: [PATCH] net: hyperv: fix a NULL pointer dereference
> >
> > In case kvmalloc_array fails, we should stop using it to avoid NULL
> > pointer dereference.
> >
> > Signed-off-by: Kangjie Lu <kjlu@umn.edu>
> > ---
>
Also, please change the subject to be more specific:
hv_netvsc: fix a possible NULL pointer dereference in netvsc_get_ethtool_stats()
Thanks.
^ permalink raw reply
* RE: [PATCH] net: hyperv: fix a NULL pointer dereference
From: Haiyang Zhang @ 2019-03-11 19:46 UTC (permalink / raw)
To: Kangjie Lu
Cc: pakki001@umn.edu, KY Srinivasan, Stephen Hemminger, Sasha Levin,
David S. Miller, linux-hyperv@vger.kernel.org,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <20190311071714.28631-1-kjlu@umn.edu>
> -----Original Message-----
> From: Kangjie Lu <kjlu@umn.edu>
> Sent: Monday, March 11, 2019 3:17 AM
> To: kjlu@umn.edu
> Cc: pakki001@umn.edu; KY Srinivasan <kys@microsoft.com>; Haiyang Zhang
> <haiyangz@microsoft.com>; Stephen Hemminger <sthemmin@microsoft.com>;
> Sasha Levin <sashal@kernel.org>; David S. Miller <davem@davemloft.net>;
> linux-hyperv@vger.kernel.org; netdev@vger.kernel.org; linux-
> kernel@vger.kernel.org
> Subject: [PATCH] net: hyperv: fix a NULL pointer dereference
>
> In case kvmalloc_array fails, we should stop using it to avoid NULL pointer
> dereference.
>
> Signed-off-by: Kangjie Lu <kjlu@umn.edu>
> ---
Reviewed-by: Haiyang Zhang <haiyangz@microsoft.com>
Thanks!
^ permalink raw reply
* [PATCH] net: hyperv: fix a NULL pointer dereference
From: Kangjie Lu @ 2019-03-11 7:17 UTC (permalink / raw)
To: kjlu
Cc: pakki001, K. Y. Srinivasan, Haiyang Zhang, Stephen Hemminger,
Sasha Levin, David S. Miller, linux-hyperv, netdev, linux-kernel
In case kvmalloc_array fails, we should stop using it to avoid
NULL pointer dereference.
Signed-off-by: Kangjie Lu <kjlu@umn.edu>
---
drivers/net/hyperv/netvsc_drv.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/net/hyperv/netvsc_drv.c b/drivers/net/hyperv/netvsc_drv.c
index cf4897043e83..4b3a03029fe8 100644
--- a/drivers/net/hyperv/netvsc_drv.c
+++ b/drivers/net/hyperv/netvsc_drv.c
@@ -1426,6 +1426,9 @@ static void netvsc_get_ethtool_stats(struct net_device *dev,
pcpu_sum = kvmalloc_array(num_possible_cpus(),
sizeof(struct netvsc_ethtool_pcpu_stats),
GFP_KERNEL);
+ if (!pcpu_sum)
+ return;
+
netvsc_get_pcpu_stats(dev, pcpu_sum);
for_each_present_cpu(cpu) {
struct netvsc_ethtool_pcpu_stats *this_sum = &pcpu_sum[cpu];
--
2.17.1
^ permalink raw reply related
* Re: [PATCH v5] Drivers: hv: vmbus: Expose monitor data only when monitor pages are used
From: Greg KH @ 2019-03-09 7:21 UTC (permalink / raw)
To: Kimberly Brown
Cc: Michael Kelley, Long Li, Sasha Levin, Stephen Hemminger,
Dexuan Cui, K. Y. Srinivasan, Haiyang Zhang, linux-hyperv,
linux-kernel
In-Reply-To: <20190308224611.GA3047@ubu-Virtual-Machine>
On Fri, Mar 08, 2019 at 05:46:11PM -0500, Kimberly Brown wrote:
> static struct kobj_type vmbus_chan_ktype = {
> .sysfs_ops = &vmbus_chan_sysfs_ops,
> .release = vmbus_chan_release,
> - .default_attrs = vmbus_chan_attrs,
As discussed on IRC, a kobj_type needs to get an attribute group one of
these days, not just a attribute list :)
So thanks for persisting with this, sorry for the earlier review
comments, you were totally right about this, nice work.
Minor review comments below:
> };
>
> /*
> @@ -1571,11 +1624,34 @@ int vmbus_add_channel_kobj(struct hv_device *dev, struct vmbus_channel *channel)
> if (ret)
> return ret;
>
> + ret = sysfs_create_group(kobj, &vmbus_chan_group);
> + channel->sysfs_group_ready = !ret;
Why do you need this flag?
> +
> + if (ret) {
> + /*
> + * If an error is returned to the calling functions, those
> + * functions will call kobject_put() on the channel kobject,
> + * which will cleanup the empty channel directory created by
> + * kobject_init_and_add().
Why is this comment needed?
> + */
> + pr_err("Unable to set up channel sysfs files\n");
dev_err() to show who had the problem with the files?
> + return ret;
> + }
> +
> kobject_uevent(kobj, KOBJ_ADD);
>
> return 0;
> }
>
> +/*
> + * vmbus_remove_channel_attr_group - remove the channel's attribute group
> + */
> +void vmbus_remove_channel_attr_group(struct vmbus_channel *channel)
> +{
> + if (channel->sysfs_group_ready)
> + sysfs_remove_group(&channel->kobj, &vmbus_chan_group);
You should be able to just always remove these, no need for a flag to
say you have created them or not, right?
thanks,
greg k-h
^ permalink raw reply
* [PATCH v5] Drivers: hv: vmbus: Expose monitor data only when monitor pages are used
From: Kimberly Brown @ 2019-03-08 22:46 UTC (permalink / raw)
To: Michael Kelley, Long Li, Sasha Levin, Stephen Hemminger,
Dexuan Cui, Greg KH
Cc: K. Y. Srinivasan, Haiyang Zhang, linux-hyperv, linux-kernel
In-Reply-To: <20190301191824.GA4108@ubu-Virtual-Machine>
There are two methods for signaling the host: the monitor page mechanism
and hypercalls. The monitor page mechanism is used by performance
critical channels (storage, networking, etc.) because it provides
improved throughput. However, latency is increased. Monitor pages are
allocated to these channels.
Monitor pages are not allocated to channels that do not use the monitor
page mechanism. Therefore, these channels do not have a valid monitor id
or valid monitor page data. In these cases, some of the "_show"
functions return incorrect data. They return an invalid monitor id and
data that is beyond the bounds of the hv_monitor_page array fields.
The "channel->offermsg.monitor_allocated" value can be used to determine
whether monitor pages have been allocated to a channel.
Add "is_visible()" callback functions for the device-level and
channel-level attribute groups. These functions will hide the monitor
sysfs files when the monitor mechanism is not used.
Remove ".default_attributes" from "vmbus_chan_attrs" and create a
channel-level attribute group, "vmbus_chan_group". These changes allow
the new "is_visible()" callback function to be applied to the
channel-level attributes. Call "sysfs_create_group()" to create the
channel sysyfs files.
Add the “bool sysfs_group_ready” field to the vmbus_channel struct.
This field is used to ensure that the attributes in the
“vmbus_chan_group” attribute group have been created. Add the
“vmbus_remove_channel_attr_group()” function, which calls
"sysfs_remove_group()" on “vmbus_chan_group” if the attributes were
created.
Signed-off-by: Kimberly Brown <kimbrownkd@gmail.com>
---
Changes in v5:
- Added the “bool sysfs_group_ready” field to vmbus_channel.
- Added the “vmbus_remove_channel_attr_group()” function which calls
"sysfs_remove_group()".
- Added a comment to "vmbus_add_channel_kobj()" to describe how the
empty directory is removed if "sysfs_create_group()" returns an
error.
- Updated the commit message.
NOTE: “.default_attrs” must be removed from vmbus_chan_ktype in order to
use the is_visible() function because "default_attrs" is an array of
attributes, not an attribute_group.
Changes in v4:
- Added “is_visible()” callback functions for the device-level and
channel-level attribute groups.
- Removed the separate monitor attribute groups proposed in v3. They’re
no longer needed because the “is_visible()” callbacks are used to
determine the attribute visibility.
- Removed "default_attributes" from "vmbus_chan_attrs" and created a
channel-level attribute group.
- Removed the "kobject_put(kobj)" call proposed in v3. The calling
functions take care of calling "kobject_put(channel->kobj)" if an
error is returned by "vmbus_add_channel_kobj()".
- Updated the commit message and subject for clarity and to reflect the
new changes in v4.
Changes in v3:
- The monitor "_show" functions no longer return an error when a
channel does not use the monitor page mechanism. Instead, the monitor
page sysfs files are created only when a channel uses the monitor
page mechanism. This change was suggested by G. Kroah-Hartman.
Note: this patch was originally patch 2/2 in a patchset. Patch 1/2 has
already been added to char-misc-testing, so I'm not resending it.
Changes in v2:
- Changed the return value for cases where monitor_allocated is not set
to "-EINVAL".
- Updated the commit message to provide more details about the monitor
page mechanism.
- Updated the sysfs documentation to describe the new return value.
Documentation/ABI/stable/sysfs-bus-vmbus | 12 +++-
drivers/hv/channel_mgmt.c | 3 +
drivers/hv/hyperv_vmbus.h | 2 +
drivers/hv/vmbus_drv.c | 80 +++++++++++++++++++++++-
include/linux/hyperv.h | 6 ++
5 files changed, 98 insertions(+), 5 deletions(-)
diff --git a/Documentation/ABI/stable/sysfs-bus-vmbus b/Documentation/ABI/stable/sysfs-bus-vmbus
index 826689dcc2e6..8e8d167eca31 100644
--- a/Documentation/ABI/stable/sysfs-bus-vmbus
+++ b/Documentation/ABI/stable/sysfs-bus-vmbus
@@ -81,7 +81,9 @@ What: /sys/bus/vmbus/devices/<UUID>/channels/<N>/latency
Date: September. 2017
KernelVersion: 4.14
Contact: Stephen Hemminger <sthemmin@microsoft.com>
-Description: Channel signaling latency
+Description: Channel signaling latency. This file is available only for
+ performance critical channels (storage, network, etc.) that use
+ the monitor page mechanism.
Users: Debugging tools
What: /sys/bus/vmbus/devices/<UUID>/channels/<N>/out_mask
@@ -95,7 +97,9 @@ What: /sys/bus/vmbus/devices/<UUID>/channels/<N>/pending
Date: September. 2017
KernelVersion: 4.14
Contact: Stephen Hemminger <sthemmin@microsoft.com>
-Description: Channel interrupt pending state
+Description: Channel interrupt pending state. This file is available only for
+ performance critical channels (storage, network, etc.) that use
+ the monitor page mechanism.
Users: Debugging tools
What: /sys/bus/vmbus/devices/<UUID>/channels/<N>/read_avail
@@ -137,7 +141,9 @@ What: /sys/bus/vmbus/devices/<UUID>/channels/<N>/monitor_id
Date: January. 2018
KernelVersion: 4.16
Contact: Stephen Hemminger <sthemmin@microsoft.com>
-Description: Monitor bit associated with channel
+Description: Monitor bit associated with channel. This file is available only
+ for performance critical channels (storage, network, etc.) that
+ use the monitor page mechanism.
Users: Debugging tools and userspace drivers
What: /sys/bus/vmbus/devices/<UUID>/channels/<N>/ring
diff --git a/drivers/hv/channel_mgmt.c b/drivers/hv/channel_mgmt.c
index 62703b354d6d..e4b1f0db8159 100644
--- a/drivers/hv/channel_mgmt.c
+++ b/drivers/hv/channel_mgmt.c
@@ -346,6 +346,9 @@ static void free_channel(struct vmbus_channel *channel)
{
tasklet_kill(&channel->callback_event);
+ /* Remove the channel sysfs attribute group */
+ vmbus_remove_channel_attr_group(channel);
+
kobject_put(&channel->kobj);
}
diff --git a/drivers/hv/hyperv_vmbus.h b/drivers/hv/hyperv_vmbus.h
index cb86b133eb4d..a94aab94e0b5 100644
--- a/drivers/hv/hyperv_vmbus.h
+++ b/drivers/hv/hyperv_vmbus.h
@@ -321,6 +321,8 @@ void vmbus_device_unregister(struct hv_device *device_obj);
int vmbus_add_channel_kobj(struct hv_device *device_obj,
struct vmbus_channel *channel);
+void vmbus_remove_channel_attr_group(struct vmbus_channel *channel);
+
struct vmbus_channel *relid2channel(u32 relid);
void vmbus_free_channels(void);
diff --git a/drivers/hv/vmbus_drv.c b/drivers/hv/vmbus_drv.c
index 000b53e5a17a..43a17e17f670 100644
--- a/drivers/hv/vmbus_drv.c
+++ b/drivers/hv/vmbus_drv.c
@@ -630,7 +630,36 @@ static struct attribute *vmbus_dev_attrs[] = {
&dev_attr_driver_override.attr,
NULL,
};
-ATTRIBUTE_GROUPS(vmbus_dev);
+
+/*
+ * Device-level attribute_group callback function. Returns the permission for
+ * each attribute, and returns 0 if an attribute is not visible.
+ */
+static umode_t vmbus_dev_attr_is_visible(struct kobject *kobj,
+ struct attribute *attr, int idx)
+{
+ struct device *dev = kobj_to_dev(kobj);
+ const struct hv_device *hv_dev = device_to_hv_device(dev);
+
+ /* Hide the monitor attributes if the monitor mechanism is not used. */
+ if (!hv_dev->channel->offermsg.monitor_allocated &&
+ (attr == &dev_attr_monitor_id.attr ||
+ attr == &dev_attr_server_monitor_pending.attr ||
+ attr == &dev_attr_client_monitor_pending.attr ||
+ attr == &dev_attr_server_monitor_latency.attr ||
+ attr == &dev_attr_client_monitor_latency.attr ||
+ attr == &dev_attr_server_monitor_conn_id.attr ||
+ attr == &dev_attr_client_monitor_conn_id.attr))
+ return 0;
+
+ return attr->mode;
+}
+
+static const struct attribute_group vmbus_dev_group = {
+ .attrs = vmbus_dev_attrs,
+ .is_visible = vmbus_dev_attr_is_visible
+};
+__ATTRIBUTE_GROUPS(vmbus_dev);
/*
* vmbus_uevent - add uevent for our device
@@ -1550,10 +1579,34 @@ static struct attribute *vmbus_chan_attrs[] = {
NULL
};
+/*
+ * Channel-level attribute_group callback function. Returns the permission for
+ * each attribute, and returns 0 if an attribute is not visible.
+ */
+static umode_t vmbus_chan_attr_is_visible(struct kobject *kobj,
+ struct attribute *attr, int idx)
+{
+ const struct vmbus_channel *channel =
+ container_of(kobj, struct vmbus_channel, kobj);
+
+ /* Hide the monitor attributes if the monitor mechanism is not used. */
+ if (!channel->offermsg.monitor_allocated &&
+ (attr == &chan_attr_pending.attr ||
+ attr == &chan_attr_latency.attr ||
+ attr == &chan_attr_monitor_id.attr))
+ return 0;
+
+ return attr->mode;
+}
+
+static struct attribute_group vmbus_chan_group = {
+ .attrs = vmbus_chan_attrs,
+ .is_visible = vmbus_chan_attr_is_visible
+};
+
static struct kobj_type vmbus_chan_ktype = {
.sysfs_ops = &vmbus_chan_sysfs_ops,
.release = vmbus_chan_release,
- .default_attrs = vmbus_chan_attrs,
};
/*
@@ -1571,11 +1624,34 @@ int vmbus_add_channel_kobj(struct hv_device *dev, struct vmbus_channel *channel)
if (ret)
return ret;
+ ret = sysfs_create_group(kobj, &vmbus_chan_group);
+ channel->sysfs_group_ready = !ret;
+
+ if (ret) {
+ /*
+ * If an error is returned to the calling functions, those
+ * functions will call kobject_put() on the channel kobject,
+ * which will cleanup the empty channel directory created by
+ * kobject_init_and_add().
+ */
+ pr_err("Unable to set up channel sysfs files\n");
+ return ret;
+ }
+
kobject_uevent(kobj, KOBJ_ADD);
return 0;
}
+/*
+ * vmbus_remove_channel_attr_group - remove the channel's attribute group
+ */
+void vmbus_remove_channel_attr_group(struct vmbus_channel *channel)
+{
+ if (channel->sysfs_group_ready)
+ sysfs_remove_group(&channel->kobj, &vmbus_chan_group);
+}
+
/*
* vmbus_device_create - Creates and registers a new child device
* on the vmbus.
diff --git a/include/linux/hyperv.h b/include/linux/hyperv.h
index 64698ec8f2ac..604a2e05af47 100644
--- a/include/linux/hyperv.h
+++ b/include/linux/hyperv.h
@@ -934,6 +934,12 @@ struct vmbus_channel {
* full outbound ring buffer.
*/
u64 out_full_first;
+
+ /*
+ * Indicates whether the channel's attribute group sysfs files have
+ * been successfully created.
+ */
+ bool sysfs_group_ready;
};
static inline bool is_hvsock_channel(const struct vmbus_channel *c)
--
2.17.1
^ permalink raw reply related
* RE: [PATCH] hyper-v: Check for ring buffer in hv_get_bytes_to_read/write
From: Michael Kelley @ 2019-03-07 19:34 UTC (permalink / raw)
To: mgamal@redhat.com, linux-hyperv@vger.kernel.org, kimbrownkd,
Haiyang Zhang, Stephen Hemminger
Cc: Sasha Levin, Dexuan Cui, Long Li, KY Srinivasan, vkuznets,
linux-kernel@vger.kernel.org
In-Reply-To: <1551983533.5436.8.camel@redhat.com>
From: Mohammed Gamal <mgamal@redhat.com> Sent: Thursday, March 7, 2019 10:32 AM
> >
> > Could you elaborate on the code paths where
> > hv_get_bytes_to_read/write() could be called when the ring buffer
> > isn't yet allocated? My sense is that Kim Brown's patch will address
> > all of the code paths that involved sysfs access from outside the
> > driver. And within a driver, the ring buffer should never be
> > accessed
> > unless it is already allocated. Is there another code path we're not
> > aware of? I'm wondering if these changes are really needed once
> > Kim Brown's patch is finished.
> >
> > Michael
>
> I've seen one instance of the race in the netvsc driver when running
> traffic through it with iperf3 while continuously changing the channel
> settings.
>
> The following code path deallocates the ring buffer:
> netvsc_set_channels() -> netvsc_detach() ->
> rndis_filter_device_remove() -> netvsc_device_remove() -> vmbus_close()
> -> vmbus_free_ring() -> hv_ringbuffer_cleanup().
>
> netvsc_send_pkt() -> hv_get_bytes_to_write() might get called
> concurrently after vmbus_close() and before vmbus_open() returns and
> sets up the new ring buffer.
>
> The race is fairly hard to reproduce on recent upstream kernels, but I
> still managed to reproduce it.
My thought is that a race like the above needs to be addressed in the
netvsc driver. The race may have other problems beyond just
accessing the ring buffer before it is (re)allocated. While adding the tests
in hv_get_bytes_to_read/write() isn't harmful, doing so has the potential
to mask the real problem. These routines are also somewhat performance
sensitive so we don't want any unnecessary overhead.
Michael
^ permalink raw reply
* Re: [PATCH] hyper-v: Check for ring buffer in hv_get_bytes_to_read/write
From: Mohammed Gamal @ 2019-03-07 18:32 UTC (permalink / raw)
To: Michael Kelley, linux-hyperv@vger.kernel.org, kimbrownkd
Cc: Sasha Levin, Dexuan Cui, Stephen Hemminger, Long Li,
KY Srinivasan, Haiyang Zhang, vkuznets,
linux-kernel@vger.kernel.org
In-Reply-To: <DM5PR2101MB09182EAC78F8EEA57E27C26AD74C0@DM5PR2101MB0918.namprd21.prod.outlook.com>
On Thu, 2019-03-07 at 17:33 +0000, Michael Kelley wrote:
> From: Mohammed Gamal <mgamal@redhat.com> Sent: Thursday, March 7,
> 2019 8:36 AM
> >
> > This patch adds a check for the presence of the ring buffer in
> > hv_get_bytes_to_read/write() to avoid possible NULL pointer
> > dereferences.
> > If the ring buffer is not yet allocated, return 0 bytes to be
> > read/written.
> >
> > The root cause is that code that accesses the ring buffer including
> > hv_get_bytes_to_read/write() could be vulnerable to the race
> > condition
> > discussed in https://lkml.org/lkml/2018/10/18/779>;
> >
> > This race is being addressed by the patch series by Kimberly Brown
> > in
> > https://lkml.org/lkml/2019/2/21/1236 which is not final yet
> >
> > Signed-off-by: Mohammed Gamal <mgamal@redhat.com>
>
> Could you elaborate on the code paths where
> hv_get_bytes_to_read/write() could be called when the ring buffer
> isn't yet allocated? My sense is that Kim Brown's patch will address
> all of the code paths that involved sysfs access from outside the
> driver. And within a driver, the ring buffer should never be
> accessed
> unless it is already allocated. Is there another code path we're not
> aware of? I'm wondering if these changes are really needed once
> Kim Brown's patch is finished.
>
> Michael
I've seen one instance of the race in the netvsc driver when running
traffic through it with iperf3 while continuously changing the channel
settings.
The following code path deallocates the ring buffer:
netvsc_set_channels() -> netvsc_detach() ->
rndis_filter_device_remove() -> netvsc_device_remove() -> vmbus_close()
-> vmbus_free_ring() -> hv_ringbuffer_cleanup().
netvsc_send_pkt() -> hv_get_bytes_to_write() might get called
concurrently after vmbus_close() and before vmbus_open() returns and
sets up the new ring buffer.
The race is fairly hard to reproduce on recent upstream kernels, but I
still managed to reproduce it.
^ permalink raw reply
* RE: [PATCH] hyper-v: Check for ring buffer in hv_get_bytes_to_read/write
From: Michael Kelley @ 2019-03-07 17:33 UTC (permalink / raw)
To: Mohammed Gamal, linux-hyperv@vger.kernel.org, kimbrownkd
Cc: Sasha Levin, Dexuan Cui, Stephen Hemminger, Long Li,
KY Srinivasan, Haiyang Zhang, vkuznets,
linux-kernel@vger.kernel.org
In-Reply-To: <20190307163606.25212-1-mgamal@redhat.com>
From: Mohammed Gamal <mgamal@redhat.com> Sent: Thursday, March 7, 2019 8:36 AM
>
> This patch adds a check for the presence of the ring buffer in
> hv_get_bytes_to_read/write() to avoid possible NULL pointer dereferences.
> If the ring buffer is not yet allocated, return 0 bytes to be read/written.
>
> The root cause is that code that accesses the ring buffer including
> hv_get_bytes_to_read/write() could be vulnerable to the race condition
> discussed in https://lkml.org/lkml/2018/10/18/779>
>
> This race is being addressed by the patch series by Kimberly Brown in
> https://lkml.org/lkml/2019/2/21/1236 which is not final yet
>
> Signed-off-by: Mohammed Gamal <mgamal@redhat.com>
Could you elaborate on the code paths where
hv_get_bytes_to_read/write() could be called when the ring buffer
isn't yet allocated? My sense is that Kim Brown's patch will address
all of the code paths that involved sysfs access from outside the
driver. And within a driver, the ring buffer should never be accessed
unless it is already allocated. Is there another code path we're not
aware of? I'm wondering if these changes are really needed once
Kim Brown's patch is finished.
Michael
^ permalink raw reply
* [PATCH] hyper-v: Check for ring buffer in hv_get_bytes_to_read/write
From: Mohammed Gamal @ 2019-03-07 16:36 UTC (permalink / raw)
To: linux-hyperv, mikelley, kimbrownkd
Cc: Alexander.Levin, decui, sthemmin, longli, kys, haiyangz, vkuznets,
linux-kernel, Mohammed Gamal
This patch adds a check for the presence of the ring buffer in
hv_get_bytes_to_read/write() to avoid possible NULL pointer dereferences.
If the ring buffer is not yet allocated, return 0 bytes to be read/written.
The root cause is that code that accesses the ring buffer including
hv_get_bytes_to_read/write() could be vulnerable to the race condition
discussed in https://lkml.org/lkml/2018/10/18/779
This race is being addressed by the patch series by Kimberly Brown in
https://lkml.org/lkml/2019/2/21/1236 which is not final yet
Signed-off-by: Mohammed Gamal <mgamal@redhat.com>
---
include/linux/hyperv.h | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/include/linux/hyperv.h b/include/linux/hyperv.h
index 64698ec8f2ac..7b2f566250b2 100644
--- a/include/linux/hyperv.h
+++ b/include/linux/hyperv.h
@@ -148,6 +148,9 @@ static inline u32 hv_get_bytes_to_read(const struct hv_ring_buffer_info *rbi)
{
u32 read_loc, write_loc, dsize, read;
+ if (!rbi->ring_buffer)
+ return 0;
+
dsize = rbi->ring_datasize;
read_loc = rbi->ring_buffer->read_index;
write_loc = READ_ONCE(rbi->ring_buffer->write_index);
@@ -162,6 +165,9 @@ static inline u32 hv_get_bytes_to_write(const struct hv_ring_buffer_info *rbi)
{
u32 read_loc, write_loc, dsize, write;
+ if (!rbi->ring_buffer)
+ return 0;
+
dsize = rbi->ring_datasize;
read_loc = READ_ONCE(rbi->ring_buffer->read_index);
write_loc = rbi->ring_buffer->write_index;
--
2.18.1
^ permalink raw reply related
* Re: [PATCH 0/3] pci-hyperv: fix memory leak and add pci_destroy_slot()
From: Stephen Hemminger @ 2019-03-05 18:27 UTC (permalink / raw)
To: Dexuan Cui
Cc: lorenzo.pieralisi@arm.com, bhelgaas@google.com,
linux-pci@vger.kernel.org, KY Srinivasan, Stephen Hemminger,
Michael Kelley, Sasha Levin, linux-hyperv@vger.kernel.org,
Haiyang Zhang, driverdev-devel@linuxdriverproject.org,
linux-kernel@vger.kernel.org, jackm@mellanox.com,
marcelo.cerri@canonical.com, olaf@aepfle.de, apw@canonical.com,
vkuznets, jasowang@redhat.com
In-Reply-To: <20190304213357.16652-1-decui@microsoft.com>
On Mon, 4 Mar 2019 21:34:47 +0000
Dexuan Cui <decui@microsoft.com> wrote:
> Patch #1 fixes a memory leak caused by incorrectly-maintained hpdev->refs.
>
> Patch #2 and #3 make sure the "slot" is removed in all the scenarios.
> Without them, in the quick hot-add/hot-remove test, systemd-dev may easily
> crash when trying to access a dangling sys file in /sys/bus/pci/slots/:
> "BUG: unable to handle kernel paging request".
>
> BTW, Patch #2 was posted on Feb 7, 2019, and this is the v2: the change
> to hv_eject_device_work() in v1 is removed, as the change is only needed
> when we hot-remove the device and remove the pci-hyperv driver at the
> same time. It looks more work is required to make this scenaro work
> correctly, and since removing the driver is not really a "usual" usage,
> we can address this scenario in the future.
>
> Please review the patchset.
>
> Dexuan Cui (3):
> PCI: hv: Fix a memory leak in hv_eject_device_work()
> PCI: hv: Add hv_pci_remove_slots() when we unload the driver
> PCI: hv: Add pci_destroy_slot() in pci_devices_present_work(), if
> necessary
>
> drivers/pci/controller/pci-hyperv.c | 23 +++++++++++++++++++++++
> 1 file changed, 23 insertions(+)
Thanks for fixing this.
Reviewed-by: Stephen Hemminger <stephen@networkplumber.org>
^ permalink raw reply
* [PATCH 1/3] PCI: hv: Fix a memory leak in hv_eject_device_work()
From: Dexuan Cui @ 2019-03-04 21:34 UTC (permalink / raw)
To: lorenzo.pieralisi@arm.com, bhelgaas@google.com,
linux-pci@vger.kernel.org, KY Srinivasan, Stephen Hemminger,
Michael Kelley, Sasha Levin
Cc: linux-hyperv@vger.kernel.org, linux-kernel@vger.kernel.org,
driverdev-devel@linuxdriverproject.org, Haiyang Zhang,
olaf@aepfle.de, apw@canonical.com, jasowang@redhat.com, vkuznets,
marcelo.cerri@canonical.com, jackm@mellanox.com, Dexuan Cui,
stable@vger.kernel.org
In-Reply-To: <20190304213357.16652-1-decui@microsoft.com>
After a device is just created in new_pcichild_device(), hpdev->refs is set
to 2 (i.e. the initial value of 1 plus the get_pcichild()).
When we hot remove the device from the host, in Linux VM we first call
hv_pci_eject_device(), which increases hpdev->refs by get_pcichild() and
then schedules a work of hv_eject_device_work(), so hpdev->refs becomes 3
(let's ignore the paired get/put_pcichild() in other places). But in
hv_eject_device_work(), currently we only call put_pcichild() twice,
meaning the 'hpdev' struct can't be freed in put_pcichild(). This patch
adds one put_pcichild() to fix the memory leak.
BTW, the device can also be removed when we run "rmmod pci-hyperv". On this
path (hv_pci_remove() -> hv_pci_bus_exit() -> hv_pci_devices_present()),
hpdev->refs is 2, and we do correctly call put_pcichild() twice in
pci_devices_present_work().
Fixes: 4daace0d8ce8 ("PCI: hv: Add paravirtual PCI front-end for Microsoft Hyper-V VMs")
Signed-off-by: Dexuan Cui <decui@microsoft.com>
Cc: <stable@vger.kernel.org>
---
drivers/pci/controller/pci-hyperv.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/pci/controller/pci-hyperv.c b/drivers/pci/controller/pci-hyperv.c
index 95441a35eceb..30f16b882746 100644
--- a/drivers/pci/controller/pci-hyperv.c
+++ b/drivers/pci/controller/pci-hyperv.c
@@ -1900,6 +1900,9 @@ static void hv_eject_device_work(struct work_struct *work)
sizeof(*ejct_pkt), (unsigned long)&ctxt.pkt,
VM_PKT_DATA_INBAND, 0);
+ /* For the get_pcichild() in hv_pci_eject_device() */
+ put_pcichild(hpdev);
+ /* For the two refs got in new_pcichild_device() */
put_pcichild(hpdev);
put_pcichild(hpdev);
put_hvpcibus(hpdev->hbus);
--
2.19.1
^ permalink raw reply related
* [PATCH 2/3] PCI: hv: Add hv_pci_remove_slots() when we unload the driver
From: Dexuan Cui @ 2019-03-04 21:34 UTC (permalink / raw)
To: lorenzo.pieralisi@arm.com, bhelgaas@google.com,
linux-pci@vger.kernel.org, KY Srinivasan, Stephen Hemminger,
Michael Kelley, Sasha Levin
Cc: linux-hyperv@vger.kernel.org, linux-kernel@vger.kernel.org,
driverdev-devel@linuxdriverproject.org, Haiyang Zhang,
olaf@aepfle.de, apw@canonical.com, jasowang@redhat.com, vkuznets,
marcelo.cerri@canonical.com, jackm@mellanox.com, Dexuan Cui,
stable@vger.kernel.org
In-Reply-To: <20190304213357.16652-1-decui@microsoft.com>
When we unload pci-hyperv, the host doesn't send us a PCI_EJECT message.
In this case we also need to make sure the sysfs pci slot directory
is removed, otherwise "cat /sys/bus/pci/slots/2/address" will trigger
"BUG: unable to handle kernel paging request" (I noticed the issue when
systemd-dev crashed for me when I unloaded the driver). And, if we
unload/reload the driver several times, we'll have multiple pci slot
directories in /sys/bus/pci/slots/ like this:
root@localhost:~# ls -rtl /sys/bus/pci/slots/
total 0
drwxr-xr-x 2 root root 0 Feb 7 10:49 2
drwxr-xr-x 2 root root 0 Feb 7 10:49 2-1
drwxr-xr-x 2 root root 0 Feb 7 10:51 2-2
The patch adds the missing code.
Fixes: a15f2c08c708 ("PCI: hv: support reporting serial number as slot information")
Signed-off-by: Dexuan Cui <decui@microsoft.com>
Acked-by: Stephen Hemminger <sthemmin@microsoft.com>
Cc: stable@vger.kernel.org
---
drivers/pci/controller/pci-hyperv.c | 16 ++++++++++++++++
1 file changed, 16 insertions(+)
diff --git a/drivers/pci/controller/pci-hyperv.c b/drivers/pci/controller/pci-hyperv.c
index 30f16b882746..b489412e3502 100644
--- a/drivers/pci/controller/pci-hyperv.c
+++ b/drivers/pci/controller/pci-hyperv.c
@@ -1486,6 +1486,21 @@ static void hv_pci_assign_slots(struct hv_pcibus_device *hbus)
}
}
+/*
+ * Remove entries in sysfs pci slot directory.
+ */
+static void hv_pci_remove_slots(struct hv_pcibus_device *hbus)
+{
+ struct hv_pci_dev *hpdev;
+
+ list_for_each_entry(hpdev, &hbus->children, list_entry) {
+ if (!hpdev->pci_slot)
+ continue;
+ pci_destroy_slot(hpdev->pci_slot);
+ hpdev->pci_slot = NULL;
+ }
+}
+
/**
* create_root_hv_pci_bus() - Expose a new root PCI bus
* @hbus: Root PCI bus, as understood by this driver
@@ -2680,6 +2695,7 @@ static int hv_pci_remove(struct hv_device *hdev)
pci_lock_rescan_remove();
pci_stop_root_bus(hbus->pci_bus);
pci_remove_root_bus(hbus->pci_bus);
+ hv_pci_remove_slots(hbus);
pci_unlock_rescan_remove();
hbus->state = hv_pcibus_removed;
}
--
2.19.1
^ permalink raw reply related
* [PATCH 3/3] PCI: hv: Add pci_destroy_slot() in pci_devices_present_work(), if necessary
From: Dexuan Cui @ 2019-03-04 21:34 UTC (permalink / raw)
To: lorenzo.pieralisi@arm.com, bhelgaas@google.com,
linux-pci@vger.kernel.org, KY Srinivasan, Stephen Hemminger,
Michael Kelley, Sasha Levin
Cc: linux-hyperv@vger.kernel.org, linux-kernel@vger.kernel.org,
driverdev-devel@linuxdriverproject.org, Haiyang Zhang,
olaf@aepfle.de, apw@canonical.com, jasowang@redhat.com, vkuznets,
marcelo.cerri@canonical.com, jackm@mellanox.com, Dexuan Cui,
stable@vger.kernel.org
In-Reply-To: <20190304213357.16652-1-decui@microsoft.com>
When we hot-remove a device, usually the host sends us a PCI_EJECT message,
and a PCI_BUS_RELATIONS message with bus_rel->device_count == 0. But when
we do the quick hot-add/hot-remove test, the host may not send us the
PCI_EJECT message, if the guest has not fully finished the initialization
by sending the PCI_RESOURCES_ASSIGNED* message to the host, so it's
potentially unsafe to only depend on the pci_destroy_slot() in
hv_eject_device_work(), though create_root_hv_pci_bus() ->
hv_pci_assign_slots() is not called in this case. Note: in this case, the
host still sends the guest a PCI_BUS_RELATIONS message with
bus_rel->device_count == 0.
And, in the quick hot-add/hot-remove test, we can have such a race: before
pci_devices_present_work() -> new_pcichild_device() adds the new device
into hbus->children, we may have already received the PCI_EJECT message,
and hence the taklet handler hv_pci_onchannelcallback() may fail to find
the "hpdev" by get_pcichild_wslot(hbus, dev_message->wslot.slot), so
hv_pci_eject_device() is NOT called; later create_root_hv_pci_bus() ->
hv_pci_assign_slots() creates the slot, and the PCI_BUS_RELATIONS message
with bus_rel->device_count == 0 removes the device from hbus->children, and
we end up being unable to remove the slot in hv_pci_remove() ->
hv_pci_remove_slots().
The patch removes the slot in pci_devices_present_work() when the device
is removed. This can address the above race. Note 1:
pci_devices_present_work() and hv_eject_device_work() run in the
singled-threaded hbus->wq, so there is not a double-remove issue for the
slot. Note 2: we can't offload hv_pci_eject_device() from
hv_pci_onchannelcallback() to the workqueue, because we need
hv_pci_onchannelcallback() synchronously call hv_pci_eject_device() to
poll the channel's ringbuffer to work around the
"hangs in hv_compose_msi_msg()" issue: see
commit de0aa7b2f97d ("PCI: hv: Fix 2 hang issues in hv_compose_msi_msg()")
Fixes: a15f2c08c708 ("PCI: hv: support reporting serial number as slot information")
Signed-off-by: Dexuan Cui <decui@microsoft.com>
Cc: stable@vger.kernel.org
---
drivers/pci/controller/pci-hyperv.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/pci/controller/pci-hyperv.c b/drivers/pci/controller/pci-hyperv.c
index b489412e3502..82acd6155adf 100644
--- a/drivers/pci/controller/pci-hyperv.c
+++ b/drivers/pci/controller/pci-hyperv.c
@@ -1776,6 +1776,10 @@ static void pci_devices_present_work(struct work_struct *work)
hpdev = list_first_entry(&removed, struct hv_pci_dev,
list_entry);
list_del(&hpdev->list_entry);
+
+ if (hpdev->pci_slot)
+ pci_destroy_slot(hpdev->pci_slot);
+
put_pcichild(hpdev);
}
--
2.19.1
^ permalink raw reply related
* [PATCH 0/3] pci-hyperv: fix memory leak and add pci_destroy_slot()
From: Dexuan Cui @ 2019-03-04 21:34 UTC (permalink / raw)
To: lorenzo.pieralisi@arm.com, bhelgaas@google.com,
linux-pci@vger.kernel.org, KY Srinivasan, Stephen Hemminger,
Michael Kelley, Sasha Levin
Cc: linux-hyperv@vger.kernel.org, linux-kernel@vger.kernel.org,
driverdev-devel@linuxdriverproject.org, Haiyang Zhang,
olaf@aepfle.de, apw@canonical.com, jasowang@redhat.com, vkuznets,
marcelo.cerri@canonical.com, jackm@mellanox.com, Dexuan Cui
Patch #1 fixes a memory leak caused by incorrectly-maintained hpdev->refs.
Patch #2 and #3 make sure the "slot" is removed in all the scenarios.
Without them, in the quick hot-add/hot-remove test, systemd-dev may easily
crash when trying to access a dangling sys file in /sys/bus/pci/slots/:
"BUG: unable to handle kernel paging request".
BTW, Patch #2 was posted on Feb 7, 2019, and this is the v2: the change
to hv_eject_device_work() in v1 is removed, as the change is only needed
when we hot-remove the device and remove the pci-hyperv driver at the
same time. It looks more work is required to make this scenaro work
correctly, and since removing the driver is not really a "usual" usage,
we can address this scenario in the future.
Please review the patchset.
Dexuan Cui (3):
PCI: hv: Fix a memory leak in hv_eject_device_work()
PCI: hv: Add hv_pci_remove_slots() when we unload the driver
PCI: hv: Add pci_destroy_slot() in pci_devices_present_work(), if
necessary
drivers/pci/controller/pci-hyperv.c | 23 +++++++++++++++++++++++
1 file changed, 23 insertions(+)
--
2.19.1
^ permalink raw reply
* Re: [PATCH v4] Drivers: hv: vmbus: Expose monitor data only when monitor pages are used
From: Greg KH @ 2019-03-04 7:38 UTC (permalink / raw)
To: Kimberly Brown
Cc: Michael Kelley, Long Li, Sasha Levin, Stephen Hemminger,
Dexuan Cui, K. Y. Srinivasan, Haiyang Zhang, linux-hyperv,
linux-kernel
In-Reply-To: <20190303211128.GA2071@ubu-Virtual-Machine>
On Sun, Mar 03, 2019 at 04:11:28PM -0500, Kimberly Brown wrote:
> On Sun, Mar 03, 2019 at 09:05:43AM +0100, Greg KH wrote:
> > On Fri, Mar 01, 2019 at 02:18:24PM -0500, Kimberly Brown wrote:
> > > +/*
> > > + * Channel-level attribute_group callback function. Returns the permission for
> > > + * each attribute, and returns 0 if an attribute is not visible.
> > > + */
> > > +static umode_t vmbus_chan_attr_is_visible(struct kobject *kobj,
> > > + struct attribute *attr, int idx)
> > > +{
> > > + const struct vmbus_channel *channel =
> > > + container_of(kobj, struct vmbus_channel, kobj);
> > > +
> > > + /* Hide the monitor attributes if the monitor mechanism is not used. */
> > > + if (!channel->offermsg.monitor_allocated &&
> > > + (attr == &chan_attr_pending.attr ||
> > > + attr == &chan_attr_latency.attr ||
> > > + attr == &chan_attr_monitor_id.attr))
> > > + return 0;
> > > +
> > > + return attr->mode;
> > > +}
> > > +
> > > +static struct attribute_group vmbus_chan_group = {
> > > + .attrs = vmbus_chan_attrs,
> > > + .is_visible = vmbus_chan_attr_is_visible
> > > +};
> > > +
> > > static struct kobj_type vmbus_chan_ktype = {
> > > .sysfs_ops = &vmbus_chan_sysfs_ops,
> > > .release = vmbus_chan_release,
> > > - .default_attrs = vmbus_chan_attrs,
> >
> > Why did you remove this line?
>
> I removed the default attributes because vmbus_chan_attrs contains
> non-default attributes. You suggested that I use one attribute_group and
> an is_visible() callback for the device-level attributes (see
> https://lore.kernel.org/lkml/20190226081848.GA15659@kroah.com/). I
> assumed (possibly incorrectly) that I should do the same for these
> channel-level attributes.
That is fine to have a callback, but why did you have to remove the
default attribute pointer? The two should have nothing to do with each
other.
> > > };
> > >
> > > /*
> > > @@ -1571,6 +1624,12 @@ int vmbus_add_channel_kobj(struct hv_device *dev, struct vmbus_channel *channel)
> > > if (ret)
> > > return ret;
> > >
> > > + ret = sysfs_create_group(kobj, &vmbus_chan_group);
> >
> > Why are you adding these "by hand"? What was wrong with using the
> > default attribute group pointer? You also are not removing the
> > attributes :(
>
> Are you referring to default_attrs in kobj_type? It's not an
> attribute_group pointer, it's a pointer to an attribute pointer array.
> The problem with using default_attrs is that all of the attributes are
> visible.
It shouldn't, the is_visable() callback will be called on each attribute
when the group is created by the core. Did that not work properly when
you tested this?
> I'm fairly certain that the monitor attributes are being removed.
> sysfs_create_group() uses the attribute_group's is_visible() callback to
> control the attribute visibility. And, when I look at the sysfs files, I
> can see that the monitor sysyfs files are removed.
I mean you are not removing the group when the device goes away, not
that the individual files are not present. If you leave the pointer to
default_attributes there, the core will properly remove the sysfs
attributes when the device is removed from the system. Otherwise you
just "get lucky" if the attributes are removed or not.
> In v3, I proposed moving the monitor attributes to a special
> attribute_group and adding that group manually when needed. Do you
> prefer that approach for the channel-level monitor attributes?
No need for a special group here, just use the is_visable() callback
like you currently are, all should be fine. I think you are adding more
code than you need to in order to get this to all work properly :)
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH v4] Drivers: hv: vmbus: Expose monitor data only when monitor pages are used
From: Kimberly Brown @ 2019-03-03 21:40 UTC (permalink / raw)
To: Michael Kelley
Cc: Long Li, Sasha Levin, Stephen Hemminger, Dexuan Cui,
gregkh@linuxfoundation.org, KY Srinivasan, Haiyang Zhang,
linux-hyperv@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <DM5PR2101MB091825C55612FBCEA3322119D7770@DM5PR2101MB0918.namprd21.prod.outlook.com>
On Sat, Mar 02, 2019 at 06:39:30PM +0000, Michael Kelley wrote:
> From: Kimberly Brown <kimbrownkd@gmail.com> Sent: Friday, March 1, 2019 11:18 AM
> >
> > +/*
> > + * Channel-level attribute_group callback function. Returns the permission for
> > + * each attribute, and returns 0 if an attribute is not visible.
> > + */
> > +static umode_t vmbus_chan_attr_is_visible(struct kobject *kobj,
> > + struct attribute *attr, int idx)
> > +{
> > + const struct vmbus_channel *channel =
> > + container_of(kobj, struct vmbus_channel, kobj);
> > +
> > + /* Hide the monitor attributes if the monitor mechanism is not used. */
> > + if (!channel->offermsg.monitor_allocated &&
> > + (attr == &chan_attr_pending.attr ||
> > + attr == &chan_attr_latency.attr ||
> > + attr == &chan_attr_monitor_id.attr))
> > + return 0;
> > +
> > + return attr->mode;
> > +}
> > +
> > +static struct attribute_group vmbus_chan_group = {
> > + .attrs = vmbus_chan_attrs,
> > + .is_visible = vmbus_chan_attr_is_visible
> > +};
> > +
> > static struct kobj_type vmbus_chan_ktype = {
> > .sysfs_ops = &vmbus_chan_sysfs_ops,
> > .release = vmbus_chan_release,
> > - .default_attrs = vmbus_chan_attrs,
>
> Just to double-check my understanding, removing the default_attrs
> here means that in vmbus_add_channel_kobj(), the call to
> kobject_init_and_add() will only create the sub-directory that is the
> channel number. The sub-directory will be empty. Then the new
> call to sysfs_create_group() that you added below will populate
> the subdirectory, as filtered by vmbus_chan_attr_is_visible().
Yes, that's my understanding as well.
>
> > };
> >
> > /*
> > @@ -1571,6 +1624,12 @@ int vmbus_add_channel_kobj(struct hv_device *dev, struct
> > vmbus_channel *channel)
> > if (ret)
> > return ret;
> >
> > + ret = sysfs_create_group(kobj, &vmbus_chan_group);
> > + if (ret) {
> > + pr_err("Unable to set up channel sysfs files\n");
> > + return ret;
>
> In this error case, the previously created sub-directory that is the
> channel number needs to be deleted/cleaned up.
I was going to let the kobject and sysfs systems take care of that. If
vmbus_add_channel_kobj() returns an error to the calling functions, they
call kobject_put(), which eventually removes the directory.
There are two functions that call vmbus_add_channel_kobj():
vmbus_add_channel_work() and vmbus_device_register(). If
vmbus_add_channel_kobj() returns an error to vmbus_add_channel_work(),
the function calls are:
free_channel() => kobject_put() (channel kobj ref. count should now be
0) => kobject_release() => kobject_cleanup() => kobject_del() =>
sysfs_remove_dir()
If vmbus_add_channel_kobject() returns an error to
vmbus_device_register(), the device's sub-directory is removed:
device_unregister() => put_device() => kobject_put() (device kobj ref.
count should now be 0) => kobject_release() => ...
So, I don't think its necessary to cleanup the subdirectory created by
kobject_init_and_add() here.
Thanks,
Kim
>
> > + }
> > +
>
> Michael
^ permalink raw reply
* Re: [PATCH v4] Drivers: hv: vmbus: Expose monitor data only when monitor pages are used
From: Kimberly Brown @ 2019-03-03 21:11 UTC (permalink / raw)
To: Greg KH
Cc: Michael Kelley, Long Li, Sasha Levin, Stephen Hemminger,
Dexuan Cui, K. Y. Srinivasan, Haiyang Zhang, linux-hyperv,
linux-kernel
In-Reply-To: <20190303080543.GA32186@kroah.com>
On Sun, Mar 03, 2019 at 09:05:43AM +0100, Greg KH wrote:
> On Fri, Mar 01, 2019 at 02:18:24PM -0500, Kimberly Brown wrote:
> > +/*
> > + * Channel-level attribute_group callback function. Returns the permission for
> > + * each attribute, and returns 0 if an attribute is not visible.
> > + */
> > +static umode_t vmbus_chan_attr_is_visible(struct kobject *kobj,
> > + struct attribute *attr, int idx)
> > +{
> > + const struct vmbus_channel *channel =
> > + container_of(kobj, struct vmbus_channel, kobj);
> > +
> > + /* Hide the monitor attributes if the monitor mechanism is not used. */
> > + if (!channel->offermsg.monitor_allocated &&
> > + (attr == &chan_attr_pending.attr ||
> > + attr == &chan_attr_latency.attr ||
> > + attr == &chan_attr_monitor_id.attr))
> > + return 0;
> > +
> > + return attr->mode;
> > +}
> > +
> > +static struct attribute_group vmbus_chan_group = {
> > + .attrs = vmbus_chan_attrs,
> > + .is_visible = vmbus_chan_attr_is_visible
> > +};
> > +
> > static struct kobj_type vmbus_chan_ktype = {
> > .sysfs_ops = &vmbus_chan_sysfs_ops,
> > .release = vmbus_chan_release,
> > - .default_attrs = vmbus_chan_attrs,
>
> Why did you remove this line?
I removed the default attributes because vmbus_chan_attrs contains
non-default attributes. You suggested that I use one attribute_group and
an is_visible() callback for the device-level attributes (see
https://lore.kernel.org/lkml/20190226081848.GA15659@kroah.com/). I
assumed (possibly incorrectly) that I should do the same for these
channel-level attributes.
> > };
> >
> > /*
> > @@ -1571,6 +1624,12 @@ int vmbus_add_channel_kobj(struct hv_device *dev, struct vmbus_channel *channel)
> > if (ret)
> > return ret;
> >
> > + ret = sysfs_create_group(kobj, &vmbus_chan_group);
>
> Why are you adding these "by hand"? What was wrong with using the
> default attribute group pointer? You also are not removing the
> attributes :(
Are you referring to default_attrs in kobj_type? It's not an
attribute_group pointer, it's a pointer to an attribute pointer array.
The problem with using default_attrs is that all of the attributes are
visible.
I'm fairly certain that the monitor attributes are being removed.
sysfs_create_group() uses the attribute_group's is_visible() callback to
control the attribute visibility. And, when I look at the sysfs files, I
can see that the monitor sysyfs files are removed.
In v3, I proposed moving the monitor attributes to a special
attribute_group and adding that group manually when needed. Do you
prefer that approach for the channel-level monitor attributes?
Thanks,
Kim
>
> greg k-h
^ permalink raw reply
* Re: [PATCH v4] Drivers: hv: vmbus: Expose monitor data only when monitor pages are used
From: Greg KH @ 2019-03-03 8:05 UTC (permalink / raw)
To: Kimberly Brown
Cc: Michael Kelley, Long Li, Sasha Levin, Stephen Hemminger,
Dexuan Cui, K. Y. Srinivasan, Haiyang Zhang, linux-hyperv,
linux-kernel
In-Reply-To: <20190301191824.GA4108@ubu-Virtual-Machine>
On Fri, Mar 01, 2019 at 02:18:24PM -0500, Kimberly Brown wrote:
> +/*
> + * Channel-level attribute_group callback function. Returns the permission for
> + * each attribute, and returns 0 if an attribute is not visible.
> + */
> +static umode_t vmbus_chan_attr_is_visible(struct kobject *kobj,
> + struct attribute *attr, int idx)
> +{
> + const struct vmbus_channel *channel =
> + container_of(kobj, struct vmbus_channel, kobj);
> +
> + /* Hide the monitor attributes if the monitor mechanism is not used. */
> + if (!channel->offermsg.monitor_allocated &&
> + (attr == &chan_attr_pending.attr ||
> + attr == &chan_attr_latency.attr ||
> + attr == &chan_attr_monitor_id.attr))
> + return 0;
> +
> + return attr->mode;
> +}
> +
> +static struct attribute_group vmbus_chan_group = {
> + .attrs = vmbus_chan_attrs,
> + .is_visible = vmbus_chan_attr_is_visible
> +};
> +
> static struct kobj_type vmbus_chan_ktype = {
> .sysfs_ops = &vmbus_chan_sysfs_ops,
> .release = vmbus_chan_release,
> - .default_attrs = vmbus_chan_attrs,
Why did you remove this line?
> };
>
> /*
> @@ -1571,6 +1624,12 @@ int vmbus_add_channel_kobj(struct hv_device *dev, struct vmbus_channel *channel)
> if (ret)
> return ret;
>
> + ret = sysfs_create_group(kobj, &vmbus_chan_group);
Why are you adding these "by hand"? What was wrong with using the
default attribute group pointer? You also are not removing the
attributes :(
greg k-h
^ permalink raw reply
* RE: [PATCH v4] Drivers: hv: vmbus: Expose monitor data only when monitor pages are used
From: Michael Kelley @ 2019-03-02 18:39 UTC (permalink / raw)
To: kimbrownkd, Long Li, Sasha Levin, Stephen Hemminger, Dexuan Cui,
gregkh@linuxfoundation.org
Cc: KY Srinivasan, Haiyang Zhang, linux-hyperv@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <20190301191824.GA4108@ubu-Virtual-Machine>
From: Kimberly Brown <kimbrownkd@gmail.com> Sent: Friday, March 1, 2019 11:18 AM
>
> +/*
> + * Channel-level attribute_group callback function. Returns the permission for
> + * each attribute, and returns 0 if an attribute is not visible.
> + */
> +static umode_t vmbus_chan_attr_is_visible(struct kobject *kobj,
> + struct attribute *attr, int idx)
> +{
> + const struct vmbus_channel *channel =
> + container_of(kobj, struct vmbus_channel, kobj);
> +
> + /* Hide the monitor attributes if the monitor mechanism is not used. */
> + if (!channel->offermsg.monitor_allocated &&
> + (attr == &chan_attr_pending.attr ||
> + attr == &chan_attr_latency.attr ||
> + attr == &chan_attr_monitor_id.attr))
> + return 0;
> +
> + return attr->mode;
> +}
> +
> +static struct attribute_group vmbus_chan_group = {
> + .attrs = vmbus_chan_attrs,
> + .is_visible = vmbus_chan_attr_is_visible
> +};
> +
> static struct kobj_type vmbus_chan_ktype = {
> .sysfs_ops = &vmbus_chan_sysfs_ops,
> .release = vmbus_chan_release,
> - .default_attrs = vmbus_chan_attrs,
Just to double-check my understanding, removing the default_attrs
here means that in vmbus_add_channel_kobj(), the call to
kobject_init_and_add() will only create the sub-directory that is the
channel number. The sub-directory will be empty. Then the new
call to sysfs_create_group() that you added below will populate
the subdirectory, as filtered by vmbus_chan_attr_is_visible().
> };
>
> /*
> @@ -1571,6 +1624,12 @@ int vmbus_add_channel_kobj(struct hv_device *dev, struct
> vmbus_channel *channel)
> if (ret)
> return ret;
>
> + ret = sysfs_create_group(kobj, &vmbus_chan_group);
> + if (ret) {
> + pr_err("Unable to set up channel sysfs files\n");
> + return ret;
In this error case, the previously created sub-directory that is the
channel number needs to be deleted/cleaned up.
> + }
> +
Michael
^ permalink raw reply
* [PATCH v4] Drivers: hv: vmbus: Expose monitor data only when monitor pages are used
From: Kimberly Brown @ 2019-03-01 19:18 UTC (permalink / raw)
To: Michael Kelley, Long Li, Sasha Levin, Stephen Hemminger,
Dexuan Cui, gregkh
Cc: K. Y. Srinivasan, Haiyang Zhang, linux-hyperv, linux-kernel
In-Reply-To: <20190226053530.GA2897@ubu-Virtual-Machine>
There are two methods for signaling the host: the monitor page mechanism
and hypercalls. The monitor page mechanism is used by performance
critical channels (storage, networking, etc.) because it provides
improved throughput. However, latency is increased. Monitor pages are
allocated to these channels.
Monitor pages are not allocated to channels that do not use the monitor
page mechanism. Therefore, these channels do not have a valid monitor id
or valid monitor page data. In these cases, some of the "_show"
functions return incorrect data. They return an invalid monitor id and
data that is beyond the bounds of the hv_monitor_page array fields.
The "channel->offermsg.monitor_allocated" value can be used to determine
whether monitor pages have been allocated to a channel.
Add "is_visible()" callback functions for the device-level and
channel-level attribute groups. These functions will hide the monitor
sysfs files when the monitor mechanism is not used.
Remove ".default_attributes" from "vmbus_chan_attrs" and create a
channel-level attribute group, "vmbus_chan_group". These changes allow
the new "is_visible()" callback function to be applied to the
channel-level attributes. Call "sysfs_create_group()" to create the
channel sysyfs files.
Signed-off-by: Kimberly Brown <kimbrownkd@gmail.com>
---
Changes in v4:
- Added “is_visible()” callback functions for the device-level and
channel-level attribute groups.
- Removed the separate monitor attribute groups proposed in v3. They’re
no longer needed because the “is_visible()” callbacks are used to
determine the attribute visibility.
- Removed "default_attributes" from "vmbus_chan_attrs" and created a
channel-level attribute group.
- Removed the "kobject_put(kobj)" call proposed in v3. The calling
functions take care of calling "kobject_put(channel->kobj)" if an
error is returned by "vmbus_add_channel_kobj()".
- Updated the commit message and subject for clarity and to reflect the
new changes in v4.
Changes in v3:
- The monitor "_show" functions no longer return an error when a
channel does not use the monitor page mechanism. Instead, the monitor
page sysfs files are created only when a channel uses the monitor
page mechanism. This change was suggested by G. Kroah-Hartman.
Note: this patch was originally patch 2/2 in a patchset. Patch 1/2 has
already been added to char-misc-testing, so I'm not resending it.
Changes in v2:
- Changed the return value for cases where monitor_allocated is not set
to "-EINVAL".
- Updated the commit message to provide more details about the monitor
page mechanism.
- Updated the sysfs documentation to describe the new return value.
Documentation/ABI/stable/sysfs-bus-vmbus | 12 +++--
drivers/hv/vmbus_drv.c | 63 +++++++++++++++++++++++-
2 files changed, 70 insertions(+), 5 deletions(-)
diff --git a/Documentation/ABI/stable/sysfs-bus-vmbus b/Documentation/ABI/stable/sysfs-bus-vmbus
index 826689dcc2e6..8e8d167eca31 100644
--- a/Documentation/ABI/stable/sysfs-bus-vmbus
+++ b/Documentation/ABI/stable/sysfs-bus-vmbus
@@ -81,7 +81,9 @@ What: /sys/bus/vmbus/devices/<UUID>/channels/<N>/latency
Date: September. 2017
KernelVersion: 4.14
Contact: Stephen Hemminger <sthemmin@microsoft.com>
-Description: Channel signaling latency
+Description: Channel signaling latency. This file is available only for
+ performance critical channels (storage, network, etc.) that use
+ the monitor page mechanism.
Users: Debugging tools
What: /sys/bus/vmbus/devices/<UUID>/channels/<N>/out_mask
@@ -95,7 +97,9 @@ What: /sys/bus/vmbus/devices/<UUID>/channels/<N>/pending
Date: September. 2017
KernelVersion: 4.14
Contact: Stephen Hemminger <sthemmin@microsoft.com>
-Description: Channel interrupt pending state
+Description: Channel interrupt pending state. This file is available only for
+ performance critical channels (storage, network, etc.) that use
+ the monitor page mechanism.
Users: Debugging tools
What: /sys/bus/vmbus/devices/<UUID>/channels/<N>/read_avail
@@ -137,7 +141,9 @@ What: /sys/bus/vmbus/devices/<UUID>/channels/<N>/monitor_id
Date: January. 2018
KernelVersion: 4.16
Contact: Stephen Hemminger <sthemmin@microsoft.com>
-Description: Monitor bit associated with channel
+Description: Monitor bit associated with channel. This file is available only
+ for performance critical channels (storage, network, etc.) that
+ use the monitor page mechanism.
Users: Debugging tools and userspace drivers
What: /sys/bus/vmbus/devices/<UUID>/channels/<N>/ring
diff --git a/drivers/hv/vmbus_drv.c b/drivers/hv/vmbus_drv.c
index 000b53e5a17a..44308220d540 100644
--- a/drivers/hv/vmbus_drv.c
+++ b/drivers/hv/vmbus_drv.c
@@ -630,7 +630,36 @@ static struct attribute *vmbus_dev_attrs[] = {
&dev_attr_driver_override.attr,
NULL,
};
-ATTRIBUTE_GROUPS(vmbus_dev);
+
+/*
+ * Device-level attribute_group callback function. Returns the permission for
+ * each attribute, and returns 0 if an attribute is not visible.
+ */
+static umode_t vmbus_dev_attr_is_visible(struct kobject *kobj,
+ struct attribute *attr, int idx)
+{
+ struct device *dev = kobj_to_dev(kobj);
+ const struct hv_device *hv_dev = device_to_hv_device(dev);
+
+ /* Hide the monitor attributes if the monitor mechanism is not used. */
+ if (!hv_dev->channel->offermsg.monitor_allocated &&
+ (attr == &dev_attr_monitor_id.attr ||
+ attr == &dev_attr_server_monitor_pending.attr ||
+ attr == &dev_attr_client_monitor_pending.attr ||
+ attr == &dev_attr_server_monitor_latency.attr ||
+ attr == &dev_attr_client_monitor_latency.attr ||
+ attr == &dev_attr_server_monitor_conn_id.attr ||
+ attr == &dev_attr_client_monitor_conn_id.attr))
+ return 0;
+
+ return attr->mode;
+}
+
+static const struct attribute_group vmbus_dev_group = {
+ .attrs = vmbus_dev_attrs,
+ .is_visible = vmbus_dev_attr_is_visible
+};
+__ATTRIBUTE_GROUPS(vmbus_dev);
/*
* vmbus_uevent - add uevent for our device
@@ -1550,10 +1579,34 @@ static struct attribute *vmbus_chan_attrs[] = {
NULL
};
+/*
+ * Channel-level attribute_group callback function. Returns the permission for
+ * each attribute, and returns 0 if an attribute is not visible.
+ */
+static umode_t vmbus_chan_attr_is_visible(struct kobject *kobj,
+ struct attribute *attr, int idx)
+{
+ const struct vmbus_channel *channel =
+ container_of(kobj, struct vmbus_channel, kobj);
+
+ /* Hide the monitor attributes if the monitor mechanism is not used. */
+ if (!channel->offermsg.monitor_allocated &&
+ (attr == &chan_attr_pending.attr ||
+ attr == &chan_attr_latency.attr ||
+ attr == &chan_attr_monitor_id.attr))
+ return 0;
+
+ return attr->mode;
+}
+
+static struct attribute_group vmbus_chan_group = {
+ .attrs = vmbus_chan_attrs,
+ .is_visible = vmbus_chan_attr_is_visible
+};
+
static struct kobj_type vmbus_chan_ktype = {
.sysfs_ops = &vmbus_chan_sysfs_ops,
.release = vmbus_chan_release,
- .default_attrs = vmbus_chan_attrs,
};
/*
@@ -1571,6 +1624,12 @@ int vmbus_add_channel_kobj(struct hv_device *dev, struct vmbus_channel *channel)
if (ret)
return ret;
+ ret = sysfs_create_group(kobj, &vmbus_chan_group);
+ if (ret) {
+ pr_err("Unable to set up channel sysfs files\n");
+ return ret;
+ }
+
kobject_uevent(kobj, KOBJ_ADD);
return 0;
--
2.17.1
^ permalink raw reply related
* Re: [GIT PULL] Hyper-V commits for v5.1
From: Greg KH @ 2019-03-01 15:46 UTC (permalink / raw)
To: Sasha Levin
Cc: linux-kernel, linux-hyperv, kys, haiyangz, sthemmin, linux-kernel
In-Reply-To: <20190301151621.486D92084F@mail.kernel.org>
On Fri, Mar 01, 2019 at 10:16:20AM -0500, Sasha Levin wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
> The following changes since commit 8834f5600cf3c8db365e18a3d5cac2c2780c81e5:
>
> Linux 5.0-rc5 (2019-02-03 13:48:04 -0800)
>
> are available in the Git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/hyperv/linux.git tags/hyperv-next-signed
pulled and pushed out, thanks.
greg k-h
^ permalink raw reply
* [GIT PULL] Hyper-V commits for v5.1
From: Sasha Levin @ 2019-03-01 15:16 UTC (permalink / raw)
To: Greg KH; +Cc: linux-kernel, linux-hyperv, kys, haiyangz, sthemmin, linux-kernel
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
The following changes since commit 8834f5600cf3c8db365e18a3d5cac2c2780c81e5:
Linux 5.0-rc5 (2019-02-03 13:48:04 -0800)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/hyperv/linux.git tags/hyperv-next-signed
for you to fetch changes up to 396ae57ef1ef978d1d21cdb7586ba184a3f22453:
Drivers: hv: vmbus: Expose counters for interrupts and full conditions (2019-02-14 20:56:10 -0500)
- ----------------------------------------------------------------
1. Exopsing counters for state changes of channel ring buffers; this is
useful to investigate performance issues. By Kimberly Brown.
2. Switching to the new generic UUID API, by Andy Shevchenko.
- ----------------------------------------------------------------
Andy Shevchenko (1):
vmbus: Switch to use new generic UUID API
Kimberly Brown (1):
Drivers: hv: vmbus: Expose counters for interrupts and full conditions
Documentation/ABI/stable/sysfs-bus-vmbus | 33 +++++++
drivers/hv/channel.c | 4 +-
drivers/hv/channel_mgmt.c | 18 ++--
drivers/hv/hyperv_vmbus.h | 4 +-
drivers/hv/ring_buffer.c | 14 ++-
drivers/hv/vmbus_drv.c | 84 +++++++++++-------
include/linux/hyperv.h | 144 ++++++++++++++++++++-----------
7 files changed, 207 insertions(+), 94 deletions(-)
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCgAdFiEE4n5dijQDou9mhzu83qZv95d3LNwFAlx5TJwACgkQ3qZv95d3
LNxZfxAAjCHHRJ2HStiHhH5tOEABQsTNYwqXB8QNwL4cBC3L0DiwihynKVy/BQzg
nwQz3dZbar2h5Qj4Wkz+ygX57Sq2kRHBYNKGygcNzBYqF0IZvcmav3xUxMUrohjq
OAAt6mfzPo/rKIoT0vq4XbtZByR3g23VJpXoE/kAf9fPnLg4LXv8xu0MWpE58mvl
9pGmD0lO7K559FlYoWZNaOKbtjayOBDa9N2Mos/KM36x9kmeF2wp06RGBe2lyKuR
fzdTJhBoYkAqVeryTox9YpdvmlCvgwmudrCChrwnpx91WJb8HM5aT8tYAOfGssiR
MArxya2qFEzuzk5ToQS0HW9Id/+08MVhB7nACON3knrpH7i6RuPq9jrVqHZZeKH1
uyiItqNs3YjTrCPhrYqzRGS572kTR2hIgRvLylq7I9GXq/PPYomo34hTrGiUDK5d
t0rT6xCAzq+4DKzwEydy4l9TpEk8IXTeJ3aiIIJLr/NgZad+IGv4aP+R01xXlUld
gN5REI8mbQ7Pvov4EPGBuLuMeMTAyXPm4W5ZYlBTZxUaT1QTx2bypX41QSaX+J/7
PCTmutjP2eIYbzcJnxvfbTS6fFJTkzLyj7HrnRrf+YotH+/NwUSP7F/fzxp5ImuL
hlC4FuvWMjSjQ/OVenVL/eqMsfPbCcdqk+eKd8HfIKKToFd6seI=
=FLip
-----END PGP SIGNATURE-----
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox