Comment 0 for bug 1927518

Revision history for this message
Tim Gardner (timg-tpi) wrote :

SRU Justification

[Impact]

Microsoft relayed a customer report of failures when trying to take a kdump.

These 3 patches fix the issue:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/video/fbdev/hyperv_fb.c?id=aa5b7d11c7cb87c266d705b237368985e7171958
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/hv/channel_mgmt.c?id=77db0ec8b7764cb9b09b78066ebfd47b2c0c1909
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/hv/channel_mgmt.c?id=8c2d5e0640e53c14b6240e9bf1e32a2226e6e6ca

Patch #1 solves a problem where the “Unable to send packet via vmbus” message is output continuously. But with that problem fixed, the second problem can occur where the kdump kernel panics due to receiving an unexpected VMbus UNLOAD complete message.

Patch #2 prevents the UNLOAD complete message from ever occurring in the kdump kernel. But if the UNLOAD complete message does occur at some unexpected time, Patch #3 prevents it from causing a panic.

[Test Plan]

Cause a guest kernel to crash and successfully acquire a kdump.

[Where problems could occur]

The extended Hyper-V wait while flushing could cause side effects.

[Other Info]
SF: #00310145
https://canonical.lightning.force.com/lightning/r/Case/5004K000005pZNNQA2