kernel/git/stable/linux-stable.git/drivers/hv/connection.c, branch linux-3.16.y

Drivers: hv: vmbus: Use get/put_cpu() in vmbus_connect()

2018-12-16T22:09:31+00:00

commit 41e270f6898e7502be9fd6920ee0a108ca259d36 upstream. With CONFIG_DEBUG_PREEMPT=y, I always see this warning: BUG: using smp_processor_id() in preemptible [00000000] Fix the false warning by using get/put_cpu(). Here vmbus_connect() sends a message to the host and waits for the host's response. The host will deliver the response message and an interrupt on CPU msg->target_vcpu, and later the interrupt handler will wake up vmbus_connect(). vmbus_connect() doesn't really have to run on the same cpu as CPU msg->target_vcpu, so it's safe to call put_cpu() just here. Signed-off-by: Dexuan Cui Cc: K. Y. Srinivasan Cc: Haiyang Zhang Cc: Stephen Hemminger Signed-off-by: K. Y. Srinivasan Signed-off-by: Greg Kroah-Hartman [bwh: Backported to 3.16: - smp_processor_id() is only used once here - Adjust context] Signed-off-by: Ben Hutchings

Drivers: hv: vmbus: Raise retry/wait limits in vmbus_post_msg()

2017-06-05T20:16:49+00:00

commit c0bb03924f1a80e7f65900e36c8e6b3dc167c5f8 upstream. DoS protection conditions were altered in WS2016 and now it's easy to get -EAGAIN returned from vmbus_post_msg() (e.g. when we try changing MTU on a netvsc device in a loop). All vmbus_post_msg() callers don't retry the operation and we usually end up with a non-functional device or crash. While host's DoS protection conditions are unknown to me my tests show that it can take up to 10 seconds before the message is sent so doing udelay() is not an option, we really need to sleep. Almost all vmbus_post_msg() callers are ready to sleep but there is one special case: vmbus_initiate_unload() which can be called from interrupt/NMI context and we can't sleep there. I'm also not sure about the lonely vmbus_send_tl_connect_request() which has no in-tree users but its external users are most likely waiting for the host to reply so sleeping there is also appropriate. Signed-off-by: Vitaly Kuznetsov Signed-off-by: K. Y. Srinivasan Signed-off-by: Greg Kroah-Hartman [bwh: Backported to 3.16: - Drop changes in vmbus_send_tl_connect_request(), vmbus_initiate_unload() - Adjust context, indentation] Signed-off-by: Ben Hutchings

Drivers: hv: vmbus: Reduce the delay between retries in vmbus_post_msg()

2017-06-05T20:16:48+00:00

commit 8de0d7e951826d7592e0ba1da655b175c4aa0923 upstream. The current delay between retries is unnecessarily high and is negatively affecting the time it takes to boot the system. Signed-off-by: K. Y. Srinivasan Signed-off-by: Greg Kroah-Hartman Signed-off-by: Ben Hutchings

hv_vmbus: Add gradually increased delay for retries in vmbus_post_msg()

2017-06-05T20:16:48+00:00

commit e1c0d82dab4a4605d3bd1968436f030dfed4a829 upstream. Most of the retries can be done within a millisecond successfully, so we sleep 1ms before the first retry, then gradually increase the retry interval to 2^n with max value of 2048ms. Doing so, we will have shorter overall delay time, because most of the cases succeed within 1-2 attempts. Signed-off-by: Haiyang Zhang Reviewed-by: K. Y. Srinivasan Reviewed-by: Dexuan Cui Signed-off-by: K. Y. Srinivasan Signed-off-by: Greg Kroah-Hartman Signed-off-by: Ben Hutchings

hv: vmbus_post_msg: retry the hypercall on some transient errors

2017-06-05T20:16:48+00:00

commit 89f9f6796d41e10e224b0cb0027ddd78cb881f65 upstream. I got HV_STATUS_INVALID_CONNECTION_ID on Hyper-V 2008 R2 when keeping running "rmmod hv_netvsc; modprobe hv_netvsc; rmmod hv_utils; modprobe hv_utils" in a Linux guest. Looks the host has some kind of throttling mechanism if some kinds of hypercalls are sent too frequently. Without the patch, the driver can occasionally fail to load. Also let's retry HV_STATUS_INSUFFICIENT_MEMORY, though we didn't get it before. Removed 'case -ENOMEM', since the hypervisor doesn't return this. CC: "K. Y. Srinivasan" Reviewed-by: Jason Wang Signed-off-by: Dexuan Cui Signed-off-by: K. Y. Srinivasan Signed-off-by: Greg Kroah-Hartman Signed-off-by: Ben Hutchings

Drivers: hv: vmbus: Cleanup vmbus_post_msg()

2014-10-30T16:40:12+00:00

commit fdeebcc62279119dbeafbc1a2e39e773839025fd upstream. Posting messages to the host can fail because of transient resource related failures. Correctly deal with these failures and increase the number of attempts to post the message before giving up. In this version of the patch, I have normalized the error code to Linux error code. Signed-off-by: K. Y. Srinivasan Tested-by: Sitsofe Wheeler Signed-off-by: Greg Kroah-Hartman

Drivers: hv: vmbus: Fix a bug in the channel callback dispatch code

2014-07-09T21:34:35+00:00

Starting with Win8, we have implemented several optimizations to improve the scalability and performance of the VMBUS transport between the Host and the Guest. Some of the non-performance critical services cannot leverage these optimization since they only read and process one message at a time. Make adjustments to the callback dispatch code to account for the way non-performance critical drivers handle reading of the channel. Signed-off-by: K. Y. Srinivasan Cc: Signed-off-by: Greg Kroah-Hartman

hv: use correct order when freeing monitor_pages

2014-05-28T20:45:15+00:00

We try to free two pages when only one has been allocated. Cleanup path is unlikely, so I haven't found any trace that would fit, but I hope that free_pages_prepare() does catch it. Cc: stable@vger.kernel.org Signed-off-by: Radim Krčmář Reviewed-by: Amos Kong Acked-by: Jason Wang Signed-off-by: Greg Kroah-Hartman

Drivers: hv: vmbus: Implement per-CPU mapping of relid to channel

2014-05-03T23:24:26+00:00

Currently the mapping of the relID to channel is done under the protection of a single spin lock. Starting with ws2012, each channel is bound to a specific VCPU in the guest. Use this binding to eliminate the spin lock by setting up per-cpu state for mapping relId to the channel. Signed-off-by: K. Y. Srinivasan Reviewed-by: Haiyang Zhang Signed-off-by: Greg Kroah-Hartman

Drivers: hv: Eliminate the channel spinlock in the callback path

2014-05-03T23:24:26+00:00

By ensuring that we set the callback handler to NULL in the channel close path on the same CPU that the channel is bound to, we can eliminate this lock acquisition and release in a performance critical path. Signed-off-by: K. Y. Srinivasan Reviewed-by: Haiyang Zhang Signed-off-by: Greg Kroah-Hartman