When a Hyper-V netvsc device is shutdown, the GPADLs for the device's large send and receive buffers are torn down. If the teardown fails, Hyper-V retain access to the buffers and may continue to read or write them. Consequently the buffers should be leaked after such an error.
Leaking the buffers used to work correctly, but was broken by a commit applied in the 4.16 kernel. This patch series restores the correct leaking behavior. Because the large buffers are allocated with wrapper functions that allow allocations larger than MAX_ORDER_NR_PAGES, leaking the memory is not as simple as setting the memory pointer to NULL so vfree() or kfree() does nothing. A new function is introduced to specify that the large buffers should be leaked. Patch 1: Fix a bug vmbus_teardown_gpadl() where an error status is lost. Patch 2: Introduce vmbus_leak_buffer() that causes vmbus_free_buffer() to leak the buffers. Patch 3: Use vmbus_leak_buffer() in the netvsc driver. Tested by hacking in code to return errors from vmbus_post_msg() and set_memory_encrypted() as called in vmbus_teardown_gpadl(). Then did unbind/rebind cycles on hv_netvsc and hv_balloon devices in a normal VM and in an SEV-SNP CoCo VM. Verified that the expected errors are generated in dmesg and that memory and vmalloc/vmap resources are freed or leaked as expected. Changes in v2: * Add a new patch as Patch 1 to correct error return from vmbus_teardown_gpadl() * Patch 3: Tweak the commit message * Patch 3: Remove now superfluous return statements Michael Kelley (3): Drivers: hv: vmbus: Fix error paths in vmbus_teardown_gpadl() Drivers: hv: Add vmbus_leak_buffer() hv_netvsc: Leak send/recv buffers if GPADL teardown fails drivers/hv/channel.c | 36 +++++++++++++++++++++++++++++++----- drivers/net/hyperv/netvsc.c | 8 ++++++-- include/linux/hyperv.h | 4 ++++ 3 files changed, 41 insertions(+), 7 deletions(-) -- 2.25.1
