kernel/linux.git/drivers/hv, branch v5.4.113

Drivers: hv: vmbus: Avoid use-after-free in vmbus_onoffer_rescind()

2021-03-04T09:26:24+00:00

[ Upstream commit e3fa4b747f085d2cda09bba0533b86fa76038635 ] When channel->device_obj is non-NULL, vmbus_onoffer_rescind() could invoke put_device(), that will eventually release the device and free the channel object (cf. vmbus_device_release()). However, a pointer to the object is dereferenced again later to load the primary_channel. The use-after-free can be avoided by noticing that this load/check is redundant if device_obj is non-NULL: primary_channel must be NULL if device_obj is non-NULL, cf. vmbus_add_channel_work(). Fixes: 54a66265d6754b ("Drivers: hv: vmbus: Fix rescind handling") Reported-by: Juan Vazquez Signed-off-by: Andrea Parri (Microsoft) Reviewed-by: Michael Kelley Link: https://lore.kernel.org/r/20201209070827.29335-5-parri.andrea@gmail.com Signed-off-by: Wei Liu Signed-off-by: Sasha Levin

Drivers: hv: vmbus: Allow cleanup of VMBUS_CONNECT_CPU if disconnected

2020-11-24T12:29:23+00:00

commit 92e4dc8b05663d6539b1b8375f3b1cf7b204cfe9 upstream. When invoking kexec() on a Linux guest running on a Hyper-V host, the kernel panics. RIP: 0010:cpuhp_issue_call+0x137/0x140 Call Trace: __cpuhp_remove_state_cpuslocked+0x99/0x100 __cpuhp_remove_state+0x1c/0x30 hv_kexec_handler+0x23/0x30 [hv_vmbus] hv_machine_shutdown+0x1e/0x30 machine_shutdown+0x10/0x20 kernel_kexec+0x6d/0x96 __do_sys_reboot+0x1ef/0x230 __x64_sys_reboot+0x1d/0x20 do_syscall_64+0x6b/0x3d8 entry_SYSCALL_64_after_hwframe+0x44/0xa9 This was due to hv_synic_cleanup() callback returning -EBUSY to cpuhp_issue_call() when tearing down the VMBUS_CONNECT_CPU, even if the vmbus_connection.conn_state = DISCONNECTED. hv_synic_cleanup() should succeed in the case where vmbus_connection.conn_state is DISCONNECTED. Fix is to add an extra condition to test for vmbus_connection.conn_state == CONNECTED on the VMBUS_CONNECT_CPU and only return early if true. This way the kexec() path can still shut everything down while preserving the initial behavior of preventing CPU offlining on the VMBUS_CONNECT_CPU while the VM is running. Fixes: 8a857c55420f29 ("Drivers: hv: vmbus: Always handle the VMBus messages on CPU0") Signed-off-by: Chris Co Reviewed-by: Andrea Parri (Microsoft) Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20201110190118.15596-1-chrco@linux.microsoft.com Signed-off-by: Wei Liu Signed-off-by: Greg Kroah-Hartman

hv_balloon: disable warning when floor reached

2020-11-18T18:20:17+00:00

[ Upstream commit 2c3bd2a5c86fe744e8377733c5e511a5ca1e14f5 ] It is not an error if the host requests to balloon down, but the VM refuses to do so. Without this change a warning is logged in dmesg every five minutes. Fixes: b3bb97b8a49f3 ("Drivers: hv: balloon: Add logging for dynamic memory operations") Signed-off-by: Olaf Hering Reviewed-by: Michael Kelley Link: https://lore.kernel.org/r/20201008071216.16554-1-olaf@aepfle.de Signed-off-by: Wei Liu Signed-off-by: Sasha Levin

Drivers: hv: vmbus: Add timeout to vmbus_wait_for_unload

2020-09-23T10:40:40+00:00

[ Upstream commit 911e1987efc8f3e6445955fbae7f54b428b92bd3 ] vmbus_wait_for_unload() looks for a CHANNELMSG_UNLOAD_RESPONSE message coming from Hyper-V. But if the message isn't found for some reason, the panic path gets hung forever. Add a timeout of 10 seconds to prevent this. Fixes: 415719160de3 ("Drivers: hv: vmbus: avoid scheduling in interrupt context in vmbus_initiate_unload()") Signed-off-by: Michael Kelley Reviewed-by: Dexuan Cui Reviewed-by: Vitaly Kuznetsov Link: https://lore.kernel.org/r/1600026449-23651-1-git-send-email-mikelley@microsoft.com Signed-off-by: Wei Liu Signed-off-by: Sasha Levin

Drivers: hv: vmbus: hibernation: do not hang forever in vmbus_bus_resume()

2020-09-23T10:40:40+00:00

[ Upstream commit 19873eec7e13fda140a0ebc75d6664e57c00bfb1 ] After we Stop and later Start a VM that uses Accelerated Networking (NIC SR-IOV), currently the VF vmbus device's Instance GUID can change, so after vmbus_bus_resume() -> vmbus_request_offers(), vmbus_onoffer() can not find the original vmbus channel of the VF, and hence we can't complete() vmbus_connection.ready_for_resume_event in check_ready_for_resume_event(), and the VM hangs in vmbus_bus_resume() forever. Fix the issue by adding a timeout, so the resuming can still succeed, and the saved state is not lost, and according to my test, the user can disable Accelerated Networking and then will be able to SSH into the VM for further recovery. Also prevent the VM in question from suspending again. The host will be fixed so in future the Instance GUID will stay the same across hibernation. Fixes: d8bd2d442bb2 ("Drivers: hv: vmbus: Resume after fixing up old primary channels") Signed-off-by: Dexuan Cui Reviewed-by: Michael Kelley Link: https://lore.kernel.org/r/20200905025555.45614-1-decui@microsoft.com Signed-off-by: Wei Liu Signed-off-by: Sasha Levin

Drivers: hv: vmbus: Ignore CHANNELMSG_TL_CONNECT_RESULT(23)

2020-08-11T13:33:38+00:00

[ Upstream commit ddc9d357b991838c2d975e8d7e4e9db26f37a7ff ] When a Linux hv_sock app tries to connect to a Service GUID on which no host app is listening, a recent host (RS3+) sends a CHANNELMSG_TL_CONNECT_RESULT (23) message to Linux and this triggers such a warning: unknown msgtype=23 WARNING: CPU: 2 PID: 0 at drivers/hv/vmbus_drv.c:1031 vmbus_on_msg_dpc Actually Linux can safely ignore the message because the Linux app's connect() will time out in 2 seconds: see VSOCK_DEFAULT_CONNECT_TIMEOUT and vsock_stream_connect(). We don't bother to make use of the message because: 1) it's only supported on recent hosts; 2) a non-trivial effort is required to use the message in Linux, but the benefit is small. So, let's not see the warning by silently ignoring the message. Signed-off-by: Dexuan Cui Reviewed-by: Michael Kelley Signed-off-by: Sasha Levin

Drivers: hv: vmbus: Always handle the VMBus messages on CPU0

2020-06-22T07:31:00+00:00

[ Upstream commit 8a857c55420f29da4fc131adc22b12d474c48f4c ] A Linux guest have to pick a "connect CPU" to communicate with the Hyper-V host. This CPU can not be taken offline because Hyper-V does not provide a way to change that CPU assignment. Current code sets the connect CPU to whatever CPU ends up running the function vmbus_negotiate_version(), and this will generate problems if that CPU is taken offine. Establish CPU0 as the connect CPU, and add logics to prevents the connect CPU from being taken offline. We could pick some other CPU, and we could pick that "other CPU" dynamically if there was a reason to do so at some point in the future. But for now, #defining the connect CPU to 0 is the most straightforward and least complex solution. While on this, add inline comments explaining "why" offer and rescind messages should not be handled by a same serialized work queue. Suggested-by: Dexuan Cui Signed-off-by: Andrea Parri (Microsoft) Reviewed-by: Vitaly Kuznetsov Link: https://lore.kernel.org/r/20200406001514.19876-2-parri.andrea@gmail.com Reviewed-by: Michael Kelley Signed-off-by: Wei Liu Signed-off-by: Sasha Levin

Drivers: hv: vmbus: Fix Suspend-to-Idle for Generation-2 VM

2020-05-06T06:15:09+00:00

commit 1a06d017fb3f388734ffbe5dedee6f8c3af5f2db upstream. Before the hibernation patchset (e.g. f53335e3289f), in a Generation-2 Linux VM on Hyper-V, the user can run "echo freeze > /sys/power/state" to freeze the system, i.e. Suspend-to-Idle. The user can press the keyboard or move the mouse to wake up the VM. With the hibernation patchset, Linux VM on Hyper-V can hibernate to disk, but Suspend-to-Idle is broken: when the synthetic keyboard/mouse are suspended, there is no way to wake up the VM. Fix the issue by not suspending and resuming the vmbus devices upon Suspend-to-Idle. Fixes: f53335e3289f ("Drivers: hv: vmbus: Suspend/resume the vmbus itself for hibernation") Cc: stable@vger.kernel.org Reviewed-by: Michael Kelley Signed-off-by: Dexuan Cui Link: https://lore.kernel.org/r/1586663435-36243-1-git-send-email-decui@microsoft.com Signed-off-by: Wei Liu Signed-off-by: Greg Kroah-Hartman

x86/Hyper-V: Free hv_panic_page when fail to register kmsg dump

2020-04-23T08:36:27+00:00

[ Upstream commit 7f11a2cc10a4ae3a70e2c73361f4a9a33503539b ] If kmsg_dump_register() fails, hv_panic_page will not be used anywhere. So free and reset it. Fixes: 81b18bce48af ("Drivers: HV: Send one page worth of kmsg dump over Hyper-V during panic") Reviewed-by: Michael Kelley Signed-off-by: Tianyu Lan Link: https://lore.kernel.org/r/20200406155331.2105-3-Tianyu.Lan@microsoft.com Signed-off-by: Wei Liu Signed-off-by: Sasha Levin

x86/Hyper-V: Report crash data in die() when panic_on_oops is set

2020-04-23T08:36:24+00:00

commit f3a99e761efa616028b255b4de58e9b5b87c5545 upstream. When oops happens with panic_on_oops unset, the oops thread is killed by die() and system continues to run. In such case, guest should not report crash register data to host since system still runs. Check panic_on_oops and return directly in hyperv_report_panic() when the function is called in the die() and panic_on_oops is unset. Fix it. Fixes: 7ed4325a44ea ("Drivers: hv: vmbus: Make panic reporting to be more useful") Signed-off-by: Tianyu Lan Reviewed-by: Michael Kelley Link: https://lore.kernel.org/r/20200406155331.2105-7-Tianyu.Lan@microsoft.com Signed-off-by: Wei Liu Signed-off-by: Greg Kroah-Hartman