> -Original Message-
> From: Greg KH [mailto:gre...@linuxfoundation.org]
> Sent: Sunday, September 10, 2017 1:10 AM
> To: KY Srinivasan
> Cc: linux-ker...@vger.kernel.org; de...@linuxdriverproject.org;
> o...@aepfle.de; a...@canonical.com; vkuzn...@redhat.com;
> jasow...@redhat.com; lean
From: "K. Y. Srinivasan"
Miscellaneous fixes.
V2: Dropped the patch: "vmbus: suppress uevents for hv_sock devices" as
this was only to address test trigerred issues.
Dexuan Cui (1):
vmbus: don't acquire the mutex in vmbus_hvsock_device_unregister()
Olaf Hering (1):
Drivers: hv: fcopy: res
From: Stephen Hemminger
This extends existing vmbus related sysfs structure to provide per-channel
state information. This is useful when diagnosing issues with multiple
queues in networking and storage.
The existing sysfs only displayed information about the primary
channel. The one place it re
From: Stephen Hemminger
When investigating performance, it is useful to be able to look at
the number of host and guest events per-channel. This is equivalent
to per-device interrupt statistics.
Signed-off-by: Stephen Hemminger
Signed-off-by: K. Y. Srinivasan
---
Documentation/ABI/stable/sysf
From: Dexuan Cui
Due to commit 54a66265d675 ("Drivers: hv: vmbus: Fix rescind handling"),
we need this patch to resolve the below deadlock:
after we get the mutex in vmbus_hvsock_device_unregister() and call
vmbus_device_unregister() -> device_unregister() -> ... -> device_release()
-> vmbus_dev
From: Olaf Hering
Till recently the expected length of bytes read by the
daemon did depend on the context. It was either hv_start_fcopy or
hv_do_fcopy. The daemon had a buffer size of two pages, which was much
larger than needed.
Now the expected length of bytes read by the
daemon changed slight
