On Mon, Dec 13, 2021 at 9:47 AM Andrea Parri [off-list ref] wrote:

Yanming,

[...]

quoted

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 the wrong read_index, receives
garbage and prints a lot of "Unhandled message: type: <garbage>" in
dmesg.

To make sure I understand your observations: Can you please print/share the
values of (desc->len8 << 3) and (desc->offset8 << 3) for such a "truncated"
packet, say, right after the

        desc = hv_pkt_iter_first(channel);

in hv_ringbuffer_read()?  Also, it'd be interesting to know whether any of

Truncated packet:
module("hv_vmbus").statement("hv_pkt_iter_first@drivers/hv/ring_buffer.c:457"):
desc->offset8 = 2, desc->len8 = 514, rbi->pkt_buffer_size = 4096
module("hv_vmbus").statement("hv_ringbuffer_read@drivers/hv/ring_buffer.c:382"):
desc->offset8 = 2, desc->len8 = 512
balloon_onchannelcallback: recvlen = 4080, dm_hdr->type = 8

First garbage packet:
module("hv_vmbus").statement("hv_pkt_iter_first@drivers/hv/ring_buffer.c:457"):
desc->offset8 = 21, desc->len8 = 16640, rbi->pkt_buffer_size = 4096
module("hv_vmbus").statement("hv_ringbuffer_read@drivers/hv/ring_buffer.c:382"):
desc->offset8 = 21, desc->len8 = 512
balloon_onchannelcallback: recvlen = 3928, dm_hdr->type = 63886

The trace proved my hypothesis above.

the two validations on pkt_len and pkt_offset in hv_pkt_iter_first() fails
(so that pkt_len/pkt_offset get updated in there).

Thanks,
  Andrea

Regards,
Yanming