Hello,
this patchset fixes skbuff merging during rx path. Problem fires when
we are trying to append data to skbuff which is processed in dequeue
callback at the same time. Dequeue callback calls 'skb_pull()' which
changes 'skb->len'. While appending data, this dynamic 'skb->len' will
be used to update length in header of last skbuff. This is wrong, because
length in header is used to update credit parameters ('rx_bytes' and
'fwd_cnt') and must be constant. To set valid length in header of last
skbuff after appending new data to it, we need to sum header values from
both last and new skbuff.
This bug was introduced by:
Fixes: 077706165717 ("virtio/vsock: don't use skbuff state to account credit")
I really forgot about this branch in rx path when implemented patch
above.
This patchset contains 3 patches:
1) Fix itself.
2) Patch with WARN() as kernel part of reproducer. I've added error
return from dequeue callback if this bug fires, otherwise you'll
get busyloop in kernel: callback always returns 0, but rx loop in
af_vsock.c sees that rx_bytes is non-zero thus trying to call
dequeue callback again and again.
3) Patch with reproducer in vsock_test.c. It looks like new test, but
i'm not sure how to test this branch (appending data to last skbuff)
of virtio transport. So only way to detect problem is WARN() in 2).
May be, it will be good practice to add some WARN() checks like in 2)
to different parts of virtio/vsock, because such bugs are difficult to
detect.
Arseniy Krasnov (3):
virtio/vsock: fix header length on skb merging
virtio/vsock: add WARN() for invalid state of socket
test/vsock: skbuff merging test
net/vmw_vsock/virtio_transport_common.c | 9 ++-
tools/testing/vsock/vsock_test.c | 81 +++++++++++++++++++++++++
2 files changed, 89 insertions(+), 1 deletion(-)
--
2.25.1
