All of lore.kernel.org
 help / color / mirror / Atom feed
From: Arseniy Krasnov <avkrasnov@sberdevices.ru>
To: Stefano Garzarella <sgarzare@redhat.com>
Cc: Stefan Hajnoczi <stefanha@redhat.com>,
	"David S. Miller" <davem@davemloft.net>,
	Eric Dumazet <edumazet@google.com>,
	Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
	Bobby Eshleman <bobby.eshleman@bytedance.com>,
	<kvm@vger.kernel.org>,
	<virtualization@lists.linux-foundation.org>,
	<netdev@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
	<kernel@sberdevices.ru>, <oxffffaa@gmail.com>
Subject: Re: [RFC PATCH v2 2/4] virtio/vsock: remove all data from sk_buff
Date: Mon, 6 Mar 2023 18:31:22 +0300	[thread overview]
Message-ID: <b18e3b13-3386-e9ee-c817-59588e6d5fb6@sberdevices.ru> (raw)
In-Reply-To: <20230306120857.6flftb3fftmsceyl@sgarzare-redhat>



On 06.03.2023 15:08, Stefano Garzarella wrote:
> On Sun, Mar 05, 2023 at 11:07:37PM +0300, Arseniy Krasnov wrote:
>> In case of SOCK_SEQPACKET all sk_buffs are used once - after read some
>> data from it, it will be removed, so user will never read rest of the
>> data. Thus we need to update credit parameters of the socket like whole
>> sk_buff is read - so call 'skb_pull()' for the whole buffer.
>>
>> Fixes: 71dc9ec9ac7d ("virtio/vsock: replace virtio_vsock_pkt with sk_buff")
>> Signed-off-by: Arseniy Krasnov <AVKrasnov@sberdevices.ru>
>> ---
>> net/vmw_vsock/virtio_transport_common.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
> 
> Maybe we could avoid this patch if we directly use pkt_len as I
> suggested in the previous patch.
Hm, may be we can avoid calling 'skb_pull()' here if 'virtio_transport_dec_rx_pkt()'
will use integer argument? Just call 'virtio_transport_dec_rx_pkt(skb->len)'. skb
is never returned to queue to read it again, so i think may be there is no sense for
extra call 'skb_pull'?

Thanks, Arseniy
> 
> Thanks,
> Stefano
> 
>>
>> diff --git a/net/vmw_vsock/virtio_transport_common.c b/net/vmw_vsock/virtio_transport_common.c
>> index 2e2a773df5c1..30b0539990ba 100644
>> --- a/net/vmw_vsock/virtio_transport_common.c
>> +++ b/net/vmw_vsock/virtio_transport_common.c
>> @@ -466,7 +466,6 @@ static int virtio_transport_seqpacket_do_dequeue(struct vsock_sock *vsk,
>>                     dequeued_len = err;
>>                 } else {
>>                     user_buf_len -= bytes_to_copy;
>> -                    skb_pull(skb, bytes_to_copy);
>>                 }
>>
>>                 spin_lock_bh(&vvs->rx_lock);
>> @@ -484,6 +483,7 @@ static int virtio_transport_seqpacket_do_dequeue(struct vsock_sock *vsk,
>>                 msg->msg_flags |= MSG_EOR;
>>         }
>>
>> +        skb_pull(skb, skb->len);
>>         virtio_transport_dec_rx_pkt(vvs, skb);
>>         kfree_skb(skb);
>>     }
>> -- 
>> 2.25.1
>>
> 

  reply	other threads:[~2023-03-06 15:36 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-05 20:04 [RFC PATCH v2 0/4] virtio/vsock: fix credit update logic Arseniy Krasnov
2023-03-05 20:06 ` [RFC PATCH v2 1/4] virtio/vsock: fix 'rx_bytes'/'fwd_cnt' calculation Arseniy Krasnov
2023-03-06 11:57   ` Stefano Garzarella
2023-03-06 11:57     ` Stefano Garzarella
2023-03-06 15:27     ` Arseniy Krasnov
2023-03-05 20:07 ` [RFC PATCH v2 2/4] virtio/vsock: remove all data from sk_buff Arseniy Krasnov
2023-03-06 12:08   ` Stefano Garzarella
2023-03-06 12:08     ` Stefano Garzarella
2023-03-06 15:31     ` Arseniy Krasnov [this message]
2023-03-06 15:51       ` Stefano Garzarella
2023-03-06 15:51         ` Stefano Garzarella
2023-03-06 16:00         ` Arseniy Krasnov
2023-03-06 16:18           ` Stefano Garzarella
2023-03-06 16:18             ` Stefano Garzarella
2023-03-07 23:53             ` Bobby Eshleman
2023-03-05 20:08 ` [RFC PATCH v2 3/4] virtio/vsock: free skb on data copy failure Arseniy Krasnov
2023-03-06 12:07   ` Stefano Garzarella
2023-03-06 12:07     ` Stefano Garzarella
2023-03-06 15:28     ` Arseniy Krasnov
2023-03-05 20:09 ` [RFC PATCH v2 4/4] test/vsock: invalid buffer tests Arseniy Krasnov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=b18e3b13-3386-e9ee-c817-59588e6d5fb6@sberdevices.ru \
    --to=avkrasnov@sberdevices.ru \
    --cc=bobby.eshleman@bytedance.com \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=kernel@sberdevices.ru \
    --cc=kuba@kernel.org \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=oxffffaa@gmail.com \
    --cc=pabeni@redhat.com \
    --cc=sgarzare@redhat.com \
    --cc=stefanha@redhat.com \
    --cc=virtualization@lists.linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.