On 06.03.2023 15:07, Stefano Garzarella wrote: > On Sun, Mar 05, 2023 at 11:08:38PM +0300, Arseniy Krasnov wrote: >> This fixes two things in case when 'memcpy_to_msg()' fails: >> 1) Update credit parameters of the socket, like this skbuff was >> copied to user successfully. This is needed because when skbuff was >> received it's length was used to update 'rx_bytes', thus when we drop >> skbuff here, we must account rest of it's data in 'rx_bytes'. >> 2) Free skbuff which was removed from socket's queue. >> >> Fixes: 71dc9ec9ac7d ("virtio/vsock: replace virtio_vsock_pkt with sk_buff") >> Signed-off-by: Arseniy Krasnov <AVKrasnov@xxxxxxxxxxxxxx> >> --- >> net/vmw_vsock/virtio_transport_common.c | 6 +++++- >> 1 file changed, 5 insertions(+), 1 deletion(-) >> >> diff --git a/net/vmw_vsock/virtio_transport_common.c b/net/vmw_vsock/virtio_transport_common.c >> index 30b0539990ba..ffb1af4f2b52 100644 >> --- a/net/vmw_vsock/virtio_transport_common.c >> +++ b/net/vmw_vsock/virtio_transport_common.c >> @@ -379,8 +379,12 @@ virtio_transport_stream_do_dequeue(struct vsock_sock *vsk, >> spin_unlock_bh(&vvs->rx_lock); >> >> err = memcpy_to_msg(msg, skb->data, bytes); >> - if (err) >> + if (err) { >> + skb_pull(skb, skb->len); >> + virtio_transport_dec_rx_pkt(vvs, skb); >> + consume_skb(skb); > > I'm not sure it's the right thing to do, if we fail to copy the content > into the user's buffer, I think we should queue it again. > > In fact, before commit 71dc9ec9ac7d ("virtio/vsock: replace > virtio_vsock_pkt with sk_buff"), we used to remove the packet from the > rx_queue, only if memcpy_to_msg() was successful. > > Maybe it is better to do as we did before and use skb_peek() at the > beginning of the loop and __skb_unlink() when skb->len == 0. Yes, i see. I'll also add test to cover this case. > > Thanks, > Stefano > >> goto out; >> + } >> >> spin_lock_bh(&vvs->rx_lock); >> >> -- >> 2.25.1 >> >