On Mon, Jan 10, 2022 at 01:44:19AM +0100, Andrea Parri wrote:

(Extending Cc: list,)

On Sun, Jan 09, 2022 at 05:55:16PM +0800, Yanming Liu wrote:

quoted

Commit adae1e931acd ("Drivers: hv: vmbus: Copy packets sent by Hyper-V
out of the ring buffer") introduced a notion of maximum packet size in
vmbus channel and used that size to initialize a buffer holding all
incoming packet along with their vmbus packet header. Currently, some
vmbus drivers set max_pkt_size to the size of their receive buffer
passed to vmbus_recvpacket, however vmbus_open expects this size to also
include vmbus packet header. This leads to corruption of the ring buffer
state when receiving a maximum sized packet.

Specifically, in hv_balloon I have observed of a dm_unballoon_request
message of 4096 bytes being truncated to 4080 bytes. When the driver
tries to read next packet it starts from a wrong read_index, receives
garbage and prints a lot of "Unhandled message: type: <garbage>" in
dmesg.

The same mismatch also happens in hv_fcopy, hv_kvp, hv_snapshot,
hv_util, hyperv_drm and hyperv_fb, though bad cases are not observed
yet.

Allocate the buffer with HV_HYP_PAGE_SIZE more bytes to make room for
the descriptor, assuming the vmbus packet header will never be larger
than HV_HYP_PAGE_SIZE. This is essentially free compared to just adding
'sizeof(struct vmpacket_descriptor)' because these buffers are all more
than HV_HYP_PAGE_SIZE bytes so kmalloc rounds them up anyway.

Fixes: adae1e931acd ("Drivers: hv: vmbus: Copy packets sent by Hyper-V out of the ring buffer")
Suggested-by: Andrea Parri (Microsoft) <parri.andrea@gmail.com>
Signed-off-by: Yanming Liu <redacted>

Thanks for sorting this out; the patch looks good to me:

Reviewed-by: Andrea Parri (Microsoft) <parri.andrea@gmail.com>

Thanks. I will pick this up after 5.17-rc1 is out.

Wei.