[ 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 <juvazq@microsoft.com>
Signed-off-by: Andrea Parri (Microsoft) <parri.andrea@gmail.com>
Reviewed-by: Michael Kelley <mikelley@microsoft.com>
Link: https://lore.kernel.org/r/20201209070827.29335-5-parri.andrea@gmail.com
Signed-off-by: Wei Liu <wei.liu@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>

Currently the kexec kernel can panic or hang due to 2 causes:

1) hv_cpu_die() is not called upon kexec, so the hypervisor corrupts the
old VP Assist Pages when the kexec kernel runs. The same issue is fixed
for hibernation in commit 421f090c819d ("x86/hyperv: Suspend/resume the
VP assist page for hibernation"). Now fix it for kexec.

2) hyperv_cleanup() is called too early. In the kexec path, the other CPUs
are stopped in hv_machine_shutdown() -> native_machine_shutdown(), so
between hv_kexec_handler() and native_machine_shutdown(), the other CPUs
can still try to access the hypercall page and cause panic. The workaround
"hv_hypercall_pg = NULL;" in hyperv_cleanup() is unreliabe. Move
hyperv_cleanup() to a better place.

Signed-off-by: Dexuan Cui <decui@microsoft.com>
Reviewed-by: Michael Kelley <mikelley@microsoft.com>
Link: https://lore.kernel.org/r/20201222065541.24312-1-decui@microsoft.com
Signed-off-by: Wei Liu <wei.liu@kernel.org>

Pull Hyper-V updates from Wei Liu:

 - harden VMBus (Andres Beltran)

 - clean up VMBus driver (Matheus Castello)

 - fix hv_balloon reporting (Vitaly Kuznetsov)

 - fix a potential OOB issue (Andrea Parri)

 - remove an obsolete TODO item (Stefan Eschenbacher)

* tag 'hyperv-next-signed-20201214' of git://git.kernel.org/pub/scm/linux/kernel/git/hyperv/linux:
  hv_balloon: do adjust_managed_page_count() when ballooning/un-ballooning
  hv_balloon: simplify math in alloc_balloon_pages()
  drivers/hv: remove obsolete TODO and fix misleading typo in comment
  drivers: hv: vmbus: Fix checkpatch SPLIT_STRING
  hv_netvsc: Validate number of allocated sub-channels
  drivers: hv: vmbus: Fix call msleep using < 20ms
  drivers: hv: vmbus: Fix checkpatch LINE_SPACING
  drivers: hv: vmbus: Replace symbolic permissions by octal permissions
  drivers: hv: Fix hyperv_record_panic_msg path on comment
  hv_netvsc: Use vmbus_requestor to generate transaction IDs for VMBus hardening
  scsi: storvsc: Use vmbus_requestor to generate transaction IDs for VMBus hardening
  Drivers: hv: vmbus: Add vmbus_requestor data structure for VMBus hardening

Unlike virtio_balloon/virtio_mem/xen balloon drivers, Hyper-V balloon driver
does not adjust managed pages count when ballooning/un-ballooning and this leads
to incorrect stats being reported, e.g. unexpected 'free' output.

Note, the calculation in post_status() seems to remain correct: ballooned out
pages are never 'available' and we manually add dm->num_pages_ballooned to
'commited'.

Suggested-by: David Hildenbrand <david@redhat.com>
Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
Reviewed-by: David Hildenbrand <david@redhat.com>
Link: https://lore.kernel.org/r/20201202161245.2406143-3-vkuznets@redhat.com
Signed-off-by: Wei Liu <wei.liu@kernel.org>

'alloc_unit' in alloc_balloon_pages() is either '512' for 2M allocations or
'1' for 4k allocations. So

1 << get_order(alloc_unit << PAGE_SHIFT)

equals to 'alloc_unit' and the for loop basically sets all them offline.
Simplify the math to improve the readability.

Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
Reviewed-by: David Hildenbrand <david@redhat.com>
Link: https://lore.kernel.org/r/20201202161245.2406143-2-vkuznets@redhat.com
Signed-off-by: Wei Liu <wei.liu@kernel.org>

Removes an obsolete TODO in the VMBus module and fixes a misleading typo
in the comment for the macro MAX_NUM_CHANNELS, where two digits have been
twisted.

Signed-off-by: Stefan Eschenbacher <stefan.eschenbacher@fau.de>
Co-developed-by: Max Stolze <max.stolze@fau.de>
Signed-off-by: Max Stolze <max.stolze@fau.de>
Link: https://lore.kernel.org/r/20201206104850.24843-1-stefan.eschenbacher@fau.de
Signed-off-by: Wei Liu <wei.liu@kernel.org>

Checkpatch emits WARNING: quoted string split across lines.
To keep the code clean and with the 80 column length indentation the
check and registration code for kmsg_dump_register has been transferred
to a new function hv_kmsg_dump_register.

Signed-off-by: Matheus Castello <matheus@castello.eng.br>
Reviewed-by: Michael Kelley <mikelley@microsoft.com>
Link: https://lore.kernel.org/r/20201125032926.17002-1-matheus@castello.eng.br
Signed-off-by: Wei Liu <wei.liu@kernel.org>

Fixed checkpatch warning: MSLEEP: msleep < 20ms can sleep for up to
20ms; see Documentation/timers/timers-howto.rst

Signed-off-by: Matheus Castello <matheus@castello.eng.br>
Reviewed-by: Michael Kelley <mikelley@microsoft.com>
Link: https://lore.kernel.org/r/20201115195734.8338-7-matheus@castello.eng.br
Signed-off-by: Wei Liu <wei.liu@kernel.org>

Fixed checkpatch warning: Missing a blank line after declarations
checkpatch(LINE_SPACING)

Signed-off-by: Matheus Castello <matheus@castello.eng.br>
Reviewed-by: Michael Kelley <mikelley@microsoft.com>
Link: https://lore.kernel.org/r/20201115195734.8338-4-matheus@castello.eng.br
Signed-off-by: Wei Liu <wei.liu@kernel.org>

This fixed the below checkpatch issue:
WARNING: Symbolic permissions 'S_IRUGO' are not preferred.
Consider using octal permissions '0444'.

Signed-off-by: Matheus Castello <matheus@castello.eng.br>
Reviewed-by: Michael Kelley <mikelley@microsoft.com>
Link: https://lore.kernel.org/r/20201115195734.8338-3-matheus@castello.eng.br
Signed-off-by: Wei Liu <wei.liu@kernel.org>