kernel/linux.git/drivers/hv, branch v4.4.235

Drivers: hv: utils: use memdup_user in hvt_op_write

2020-05-10T08:26:03+00:00

commit b00359642c2427da89dc8f77daa2c9e8a84e6d76 upstream. Use memdup_user to handle OOM. Fixes: 14b50f80c32d ('Drivers: hv: util: introduce hv_utils_transport abstraction') Signed-off-by: Olaf Hering Signed-off-by: K. Y. Srinivasan Signed-off-by: Greg Kroah-Hartman

Drivers: hv: vmbus: Return -EINVAL for the sys files for unopened channels

2019-01-13T09:05:27+00:00

commit fc96df16a1ce80cbb3c316ab7d4dc8cd5c2852ce upstream. Before 98f4c651762c, we returned zeros for unopened channels. With 98f4c651762c, we started to return random on-stack values. We'd better return -EINVAL instead. Fixes: 98f4c651762c ("hv: move ringbuffer bus attributes to dev_groups") Cc: stable@vger.kernel.org Cc: K. Y. Srinivasan Cc: Haiyang Zhang Cc: Stephen Hemminger Signed-off-by: Dexuan Cui Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman

HV: properly delay KVP packets when negotiation is in progress

2018-10-20T07:52:38+00:00

commit a3ade8cc474d848676278660e65f5af1e9e094d9 upstream. The host may send multiple negotiation packets (due to timeout) before the KVP user-mode daemon is connected. KVP user-mode daemon is connected. We need to defer processing those packets until the daemon is negotiated and connected. It's okay for guest to respond to all negotiation packets. In addition, the host may send multiple staged KVP requests as soon as negotiation is done. We need to properly process those packets using one tasklet for exclusive access to ring buffer. This patch is based on the work of Nick Meier . The above is the original changelog of a3ade8cc474d ("HV: properly delay KVP packets when negotiation is in progress" Here I re-worked the original patch because the mainline version can't work for the linux-4.4.y branch, on which channel->callback_event doesn't exist yet. In the mainline, channel->callback_event was added by: 631e63a9f346 ("vmbus: change to per channel tasklet"). Here we don't want to backport it to v4.4, as it requires extra supporting changes and fixes, which are unnecessary as to the KVP bug we're trying to resolve. NOTE: before this patch is used, we should cherry-pick the other related 3 patches from the mainline first: The background of this backport request is that: recently Wang Jian reported some KVP issues: https://github.com/LIS/lis-next/issues/593: e.g. the /var/lib/hyperv/.kvp_pool_* files can not be updated, and sometimes if the hv_kvp_daemon doesn't timely start, the host may not be able to query the VM's IP address via KVP. Reported-by: Wang Jian Tested-by: Wang Jian Signed-off-by: Dexuan Cui Signed-off-by: Long Li Signed-off-by: K. Y. Srinivasan Signed-off-by: Greg Kroah-Hartman

Drivers: hv: kvp: fix IP Failover

2018-10-20T07:52:38+00:00

commit 4dbfc2e68004c60edab7e8fd26784383dd3ee9bc upstream. Hyper-V VMs can be replicated to another hosts and there is a feature to set different IP for replicas, it is called 'Failover TCP/IP'. When such guest starts Hyper-V host sends it KVP_OP_SET_IP_INFO message as soon as we finish negotiation procedure. The problem is that it can happen (and it actually happens) before userspace daemon connects and we reply with HV_E_FAIL to the message. As there are no repetitions we fail to set the requested IP. Solve the issue by postponing our reply to the negotiation message till userspace daemon is connected. We can't wait too long as there is a host-side timeout (cca. 75 seconds) and if we fail to reply in this time frame the whole KVP service will become inactive. The solution is not ideal - if it takes userspace daemon more than 60 seconds to connect IP Failover will still fail but I don't see a solution with our current separation between kernel and userspace parts. Other two modules (VSS and FCOPY) don't require such delay, leave them untouched. Signed-off-by: Vitaly Kuznetsov Signed-off-by: K. Y. Srinivasan Signed-off-by: Dexuan Cui Signed-off-by: Greg Kroah-Hartman

Drivers: hv: util: Pass the channel information during the init call

2018-10-20T07:52:38+00:00

commit b9830d120cbe155863399f25eaef6aa8353e767f upstream. Pass the channel information to the util drivers that need to defer reading the channel while they are processing a request. This would address the following issue reported by Vitaly: Commit 3cace4a61610 ("Drivers: hv: utils: run polling callback always in interrupt context") removed direct *_transaction.state = HVUTIL_READY assignments from *_handle_handshake() functions introducing the following race: if a userspace daemon connects before we get first non-negotiation request from the server hv_poll_channel() won't set transaction state to HVUTIL_READY as (!channel) condition will fail, we set it to non-NULL on the first real request from the server. Signed-off-by: K. Y. Srinivasan Reported-by: Vitaly Kuznetsov Signed-off-by: Dexuan Cui Signed-off-by: Greg Kroah-Hartman

Drivers: hv: utils: Invoke the poll function after handshake

2018-10-20T07:52:38+00:00

commit 2d0c3b5ad739697a68dc8a444f5b9f4817cf8f8f upstream. When the handshake with daemon is complete, we should poll the channel since during the handshake, we will not be processing any messages. This is a potential bug if the host is waiting for a response from the guest. I would like to thank Dexuan for pointing this out. Signed-off-by: K. Y. Srinivasan Signed-off-by: Dexuan Cui Signed-off-by: Greg Kroah-Hartman

Drivers: hv: vmbus: fix build warning

2018-02-25T10:03:46+00:00

commit 9220e39b5c900c67ddcb517d52fe52d90fb5e3c8 upstream. We were getting build warning about unused variable "tsc_msr" and "va_tsc" while building for i386 allmodconfig. Signed-off-by: Sudip Mukherjee Signed-off-by: Greg Kroah-Hartman

x86/retpoline/hyperv: Convert assembler indirect jumps

2018-01-23T18:50:13+00:00

commit e70e5892b28c18f517f29ab6e83bd57705104b31 upstream. Convert all indirect jumps in hyperv inline asm code to use non-speculative sequences when CONFIG_RETPOLINE is enabled. Signed-off-by: David Woodhouse Signed-off-by: Thomas Gleixner Acked-by: Arjan van de Ven Acked-by: Ingo Molnar Cc: gnomes@lxorguk.ukuu.org.uk Cc: Rik van Riel Cc: Andi Kleen Cc: Josh Poimboeuf Cc: thomas.lendacky@amd.com Cc: Peter Zijlstra Cc: Linus Torvalds Cc: Jiri Kosina Cc: Andy Lutomirski Cc: Dave Hansen Cc: Kees Cook Cc: Tim Chen Cc: Greg Kroah-Hartman Cc: Paul Turner Link: https://lkml.kernel.org/r/1515707194-20531-9-git-send-email-dwmw@amazon.co.uk [ backport to 4.4, hopefully correct, not tested... - gregkh ] Signed-off-by: Greg Kroah-Hartman

Drivers: hv: fcopy: restore correct transfer length

2017-10-12T09:27:33+00:00

commit 549e658a0919e355a2b2144dc380b3729bef7f3e upstream. 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 slightly. For START_FILE_COPY it is still the size of hv_start_fcopy. But for WRITE_TO_FILE and the other operations it is as large as the buffer that arrived via vmbus. In case of WRITE_TO_FILE that is slightly larger than a struct hv_do_fcopy. Since the buffer in the daemon was still larger everything was fine. Currently, the daemon reads only what is actually needed. The new buffer layout is as large as a struct hv_do_fcopy, for the WRITE_TO_FILE operation. Since the kernel expects a slightly larger size, hvt_op_read will return -EINVAL because the daemon will read slightly less than expected. Address this by restoring the expected buffer size in case of WRITE_TO_FILE. Fixes: 'c7e490fc23eb ("Drivers: hv: fcopy: convert to hv_utils_transport")' Fixes: '3f2baa8a7d2e ("Tools: hv: update buffer handling in hv_fcopy_daemon")' Signed-off-by: Olaf Hering Signed-off-by: K. Y. Srinivasan Signed-off-by: Greg Kroah-Hartman Signed-off-by: Greg Kroah-Hartman

hv: don't reset hv_context.tsc_page on crash

2017-04-27T07:09:34+00:00

commit 56ef6718a1d8d77745033c5291e025ce18504159 upstream. It may happen that secondary CPUs are still alive and resetting hv_context.tsc_page will cause a consequent crash in read_hv_clock_tsc() as we don't check for it being not NULL there. It is safe as we're not freeing this page anyways. Signed-off-by: Vitaly Kuznetsov Signed-off-by: K. Y. Srinivasan Signed-off-by: Sumit Semwal Signed-off-by: Greg Kroah-Hartman