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

hv_balloon: Balloon up according to request page number

2020-02-11T12:34:01+00:00

commit d33c240d47dab4fd15123d9e73fc8810cbc6ed6a upstream. Current code has assumption that balloon request memory size aligns with 2MB. But actually Hyper-V doesn't guarantee such alignment. When balloon driver receives non-aligned balloon request, it produces warning and balloon up more memory than requested in order to keep 2MB alignment. Remove the warning and balloon up memory according to actual requested memory size. Fixes: f6712238471a ("hv: hv_balloon: avoid memory leak on alloc_error of 2MB memory block") Cc: stable@vger.kernel.org Reviewed-by: Vitaly Kuznetsov Signed-off-by: Tianyu Lan Reviewed-by: Michael Kelley Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman

vmbus: keep pointer to ring buffer page

2019-11-20T17:47:31+00:00

[ Upstream commit 52a42c2a90226dc61c99bbd0cb096deeb52c334b ] Avoid going from struct page to virt address (and back) by just keeping pointer to the allocated pages instead of virt address. Signed-off-by: Stephen Hemminger Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin

Drivers: hv: vmbus: Fix synic per-cpu context initialization

2019-11-20T17:46:31+00:00

[ Upstream commit f25a7ece08bdb1f2b3c4bbeae942682fc3a99dde ] If hv_synic_alloc() errors out, the state of the per-cpu context for some CPUs is unknown since the zero'ing is done as each CPU is iterated over. In such case, hv_synic_cleanup() may try to free memory based on uninitialized values. Fix this by zero'ing the per-cpu context for all CPUs before doing any memory allocations that might fail. Signed-off-by: Michael Kelley Reported-by: Dan Carpenter Signed-off-by: K. Y. Srinivasan Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin

Drivers: hv: kvp: Fix the recent regression caused by incorrect clean-up

2019-09-16T06:21:54+00:00

[ Upstream commit e670de54c813b5bc3672dd1c67871dc60e9206f4 ] In kvp_send_key(), we do need call process_ib_ipinfo() if message->kvp_hdr.operation is KVP_OP_GET_IP_INFO, because it turns out the userland hv_kvp_daemon needs the info of operation, adapter_id and addr_family. With the incorrect fc62c3b1977d, the host can't get the VM's IP via KVP. And, fc62c3b1977d added a "break;", but actually forgot to initialize the key_size/value in the case of KVP_OP_SET, so the default key_size of 0 is passed to the kvp daemon, and the pool files /var/lib/hyperv/.kvp_pool_* can't be updated. This patch effectively rolls back the previous fc62c3b1977d, and correctly fixes the "this statement may fall through" warnings. This patch is tested on WS 2012 R2 and 2016. Fixes: fc62c3b1977d ("Drivers: hv: kvp: Fix two "this statement may fall through" warnings") Signed-off-by: Dexuan Cui Cc: K. Y. Srinivasan Cc: Stephen Hemminger Signed-off-by: Haiyang Zhang Cc: Signed-off-by: K. Y. Srinivasan Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin

Drivers: hv: kvp: Fix the indentation of some "break" statements

2019-09-16T06:21:53+00:00

[ Upstream commit d544c22d6951be3386ac59bb9a99c9bc566b3f09 ] No functional change. 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 Signed-off-by: Sasha Levin

Drivers: hv: kvp: Fix two "this statement may fall through" warnings

2019-09-16T06:21:48+00:00

[ Upstream commit fc62c3b1977d62e6374fd6e28d371bb42dfa5c9d ] We don't need to call process_ib_ipinfo() if message->kvp_hdr.operation is KVP_OP_GET_IP_INFO in kvp_send_key(), because here we just need to pass on the op code from the host to the userspace; when the userspace returns the info requested by the host, we pass the info on to the host in kvp_respond_to_host() -> process_ob_ipinfo(). BTW, the current buggy code actually doesn't cause any harm, because only message->kvp_hdr.operation is used by the userspace, in the case of KVP_OP_GET_IP_INFO. The patch also adds a missing "break;" in kvp_send_key(). BTW, the current buggy code actually doesn't cause any harm, because in the case of KVP_OP_SET, the unexpected fall-through corrupts message->body.kvp_set.data.key_size, but that is not really used: see the definition of struct hv_kvp_exchg_msg_value. Signed-off-by: Dexuan Cui Cc: K. Y. Srinivasan Cc: Haiyang Zhang Cc: Stephen Hemminger Cc: Signed-off-by: K. Y. Srinivasan Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin

Drivers: hv: vmbus: Fix virt_to_hvpfn() for X86_PAE

2019-08-29T06:28:51+00:00

commit a9fc4340aee041dd186d1fb8f1b5d1e9caf28212 upstream. In the case of X86_PAE, unsigned long is u32, but the physical address type should be u64. Due to the bug here, the netvsc driver can not load successfully, and sometimes the VM can panic due to memory corruption (the hypervisor writes data to the wrong location). Fixes: 6ba34171bcbd ("Drivers: hv: vmbus: Remove use of slow_virt_to_phys()") Cc: stable@vger.kernel.org Cc: Michael Kelley Reported-and-tested-by: Juliana Rodrigueiro Signed-off-by: Dexuan Cui Reviewed-by: Michael Kelley Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman

Drivers: hv: vmbus: Remove the undesired put_cpu_ptr() in hv_synic_cleanup()

2019-05-10T15:54:04+00:00

commit a0033bd1eae4650b69be07c17cb87393da584563 upstream. With CONFIG_DEBUG_PREEMPT=y, the put_cpu_ptr() triggers an underflow warning in preempt_count_sub(). Fixes: 37cdd991fac8 ("vmbus: put related per-cpu variable together") Cc: stable@vger.kernel.org Cc: Stephen Hemminger Signed-off-by: Dexuan Cui Reviewed-by: Michael Kelley Signed-off-by: Sasha Levin (Microsoft) Signed-off-by: Greg Kroah-Hartman

Drivers: hv: vmbus: Check for ring when getting debug info

2019-01-31T07:14:36+00:00

commit ba50bf1ce9a51fc97db58b96d01306aa70bc3979 upstream. fc96df16a1ce is good and can already fix the "return stack garbage" issue, but let's also improve hv_ringbuffer_get_debuginfo(), which would silently return stack garbage, if people forget to check channel->state or ring_info->ring_buffer, when using the function in the future. Having an error check in the function would eliminate the potential risk. Add a Fixes tag to indicate the patch depdendency. Fixes: fc96df16a1ce ("Drivers: hv: vmbus: Return -EINVAL for the sys files for unopened channels") Cc: stable@vger.kernel.org Cc: K. Y. Srinivasan Cc: Haiyang Zhang Signed-off-by: Stephen Hemminger Signed-off-by: Dexuan Cui Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman

hv_balloon: avoid touching uninitialized struct page during tail onlining

2019-01-31T07:14:36+00:00

commit da8ced360ca8ad72d8f41f5c8fcd5b0e63e1555f upstream. Hyper-V memory hotplug protocol has 2M granularity and in Linux x86 we use 128M. To deal with it we implement partial section onlining by registering custom page onlining callback (hv_online_page()). Later, when more memory arrives we try to online the 'tail' (see hv_bring_pgs_online()). It was found that in some cases this 'tail' onlining causes issues: BUG: Bad page state in process kworker/0:2 pfn:109e3a page:ffffe08344278e80 count:0 mapcount:1 mapping:0000000000000000 index:0x0 flags: 0xfffff80000000() raw: 000fffff80000000 dead000000000100 dead000000000200 0000000000000000 raw: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 page dumped because: nonzero mapcount ... Workqueue: events hot_add_req [hv_balloon] Call Trace: dump_stack+0x5c/0x80 bad_page.cold.112+0x7f/0xb2 free_pcppages_bulk+0x4b8/0x690 free_unref_page+0x54/0x70 hv_page_online_one+0x5c/0x80 [hv_balloon] hot_add_req.cold.24+0x182/0x835 [hv_balloon] ... Turns out that we now have deferred struct page initialization for memory hotplug so e.g. memory_block_action() in drivers/base/memory.c does pages_correctly_probed() check and in that check it avoids inspecting struct pages and checks sections instead. But in Hyper-V balloon driver we do PageReserved(pfn_to_page()) check and this is now wrong. Switch to checking online_section_nr() instead. Signed-off-by: Vitaly Kuznetsov Cc: stable@kernel.org Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman