kvm.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Stefano Garzarella <sgarzare@redhat.com>
To: Arseny Krasnov <arseny.krasnov@kaspersky.com>
Cc: Stefan Hajnoczi <stefanha@redhat.com>,
	"Michael S. Tsirkin" <mst@redhat.com>,
	Jason Wang <jasowang@redhat.com>,
	"David S. Miller" <davem@davemloft.net>,
	Jakub Kicinski <kuba@kernel.org>,
	Jorgen Hansen <jhansen@vmware.com>,
	Norbert Slusarek <nslusarek@gmx.net>,
	Colin Ian King <colin.king@canonical.com>,
	Andra Paraschiv <andraprs@amazon.com>,
	"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
	"virtualization@lists.linux-foundation.org" 
	<virtualization@lists.linux-foundation.org>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"oxffffaa@gmail.com" <oxffffaa@gmail.com>
Subject: Re: [PATCH v10 11/18] virtio/vsock: dequeue callback for SOCK_SEQPACKET
Date: Mon, 7 Jun 2021 13:04:21 +0200	[thread overview]
Message-ID: <20210607110421.wkx4dj7wipwsqztj@steredhat> (raw)
In-Reply-To: <a81ae3cb-439f-7621-4ae6-bccd2c25b7e4@kaspersky.com>

On Fri, Jun 04, 2021 at 09:03:26PM +0300, Arseny Krasnov wrote:
>
>On 04.06.2021 18:03, Stefano Garzarella wrote:
>> On Fri, Jun 04, 2021 at 04:12:23PM +0300, Arseny Krasnov wrote:
>>> On 03.06.2021 17:45, Stefano Garzarella wrote:
>>>> On Thu, May 20, 2021 at 10:17:58PM +0300, Arseny Krasnov wrote:
>>>>> Callback fetches RW packets from rx queue of socket until whole record
>>>>> is copied(if user's buffer is full, user is not woken up). This is done
>>>>> to not stall sender, because if we wake up user and it leaves syscall,
>>>>> nobody will send credit update for rest of record, and sender will wait
>>>>> for next enter of read syscall at receiver's side. So if user buffer is
>>>>> full, we just send credit update and drop data.
>>>>>
>>>>> Signed-off-by: Arseny Krasnov <arseny.krasnov@kaspersky.com>
>>>>> ---
>>>>> v9 -> v10:
>>>>> 1) Number of dequeued bytes incremented even in case when
>>>>>    user's buffer is full.
>>>>> 2) Use 'msg_data_left()' instead of direct access to 'msg_hdr'.
>>>>> 3) Rename variable 'err' to 'dequeued_len', in case of error
>>>>>    it has negative value.
>>>>>
>>>>> include/linux/virtio_vsock.h            |  5 ++
>>>>> net/vmw_vsock/virtio_transport_common.c | 65 +++++++++++++++++++++++++
>>>>> 2 files changed, 70 insertions(+)
>>>>>
>>>>> diff --git a/include/linux/virtio_vsock.h b/include/linux/virtio_vsock.h
>>>>> index dc636b727179..02acf6e9ae04 100644
>>>>> --- a/include/linux/virtio_vsock.h
>>>>> +++ b/include/linux/virtio_vsock.h
>>>>> @@ -80,6 +80,11 @@ virtio_transport_dgram_dequeue(struct vsock_sock *vsk,
>>>>> 			       struct msghdr *msg,
>>>>> 			       size_t len, int flags);
>>>>>
>>>>> +ssize_t
>>>>> +virtio_transport_seqpacket_dequeue(struct vsock_sock *vsk,
>>>>> +				   struct msghdr *msg,
>>>>> +				   int flags,
>>>>> +				   bool *msg_ready);
>>>>> s64 virtio_transport_stream_has_data(struct vsock_sock *vsk);
>>>>> s64 virtio_transport_stream_has_space(struct vsock_sock *vsk);
>>>>>
>>>>> diff --git a/net/vmw_vsock/virtio_transport_common.c b/net/vmw_vsock/virtio_transport_common.c
>>>>> index ad0d34d41444..61349b2ea7fe 100644
>>>>> --- a/net/vmw_vsock/virtio_transport_common.c
>>>>> +++ b/net/vmw_vsock/virtio_transport_common.c
>>>>> @@ -393,6 +393,59 @@ virtio_transport_stream_do_dequeue(struct vsock_sock *vsk,
>>>>> 	return err;
>>>>> }
>>>>>
>>>>> +static int virtio_transport_seqpacket_do_dequeue(struct vsock_sock *vsk,
>>>>> +						 struct msghdr *msg,
>>>>> +						 int flags,
>>>>> +						 bool *msg_ready)
>>>>> +{
>>>>> +	struct virtio_vsock_sock *vvs = vsk->trans;
>>>>> +	struct virtio_vsock_pkt *pkt;
>>>>> +	int dequeued_len = 0;
>>>>> +	size_t user_buf_len = msg_data_left(msg);
>>>>> +
>>>>> +	*msg_ready = false;
>>>>> +	spin_lock_bh(&vvs->rx_lock);
>>>>> +
>>>>> +	while (!*msg_ready && !list_empty(&vvs->rx_queue) && dequeued_len >= 0) {
>>>> I'
>>>>
>>>>> +		size_t bytes_to_copy;
>>>>> +		size_t pkt_len;
>>>>> +
>>>>> +		pkt = list_first_entry(&vvs->rx_queue, struct virtio_vsock_pkt, list);
>>>>> +		pkt_len = (size_t)le32_to_cpu(pkt->hdr.len);
>>>>> +		bytes_to_copy = min(user_buf_len, pkt_len);
>>>>> +
>>>>> +		if (bytes_to_copy) {
>>>>> +			/* sk_lock is held by caller so no one else can dequeue.
>>>>> +			 * Unlock rx_lock since memcpy_to_msg() may sleep.
>>>>> +			 */
>>>>> +			spin_unlock_bh(&vvs->rx_lock);
>>>>> +
>>>>> +			if (memcpy_to_msg(msg, pkt->buf, bytes_to_copy))
>>>>> +				dequeued_len = -EINVAL;
>>>> I think here is better to return the error returned by memcpy_to_msg(),
>>>> as we do in the other place where we use memcpy_to_msg().
>>>>
>>>> I mean something like this:
>>>> 			err = memcpy_to_msgmsg, pkt->buf, bytes_to_copy);
>>>> 			if (err)
>>>> 				dequeued_len = err;
>>> Ack
>>>>> +			else
>>>>> +				user_buf_len -= bytes_to_copy;
>>>>> +
>>>>> +			spin_lock_bh(&vvs->rx_lock);
>>>>> +		}
>>>>> +
>>>> Maybe here we can simply break the cycle if we have an error:
>>>> 		if (dequeued_len < 0)
>>>> 			break;
>>>>
>>>> Or we can refactor a bit, simplifying the while() condition and also the
>>>> code in this way (not tested):
>>>>
>>>> 	while (!*msg_ready && !list_empty(&vvs->rx_queue)) {
>>>> 		...
>>>>
>>>> 		if (bytes_to_copy) {
>>>> 			int err;
>>>>
>>>> 			/* ...
>>>> 			*/
>>>> 			spin_unlock_bh(&vvs->rx_lock);
>>>> 			err = memcpy_to_msgmsg, pkt->buf, bytes_to_copy);
>>>> 			if (err) {
>>>> 				dequeued_len = err;
>>>> 				goto out;
>>>> 			}
>>>> 			spin_lock_bh(&vvs->rx_lock);
>>>>
>>>> 			user_buf_len -= bytes_to_copy;
>>>> 		}
>>>>
>>>> 		dequeued_len += pkt_len;
>>>>
>>>> 		if (le32_to_cpu(pkt->hdr.flags) & VIRTIO_VSOCK_SEQ_EOR)
>>>> 			*msg_ready = true;
>>>>
>>>> 		virtio_transport_dec_rx_pkt(vvs, pkt);
>>>> 		list_del(&pkt->list);
>>>> 		virtio_transport_free_pkt(pkt);
>>>> 	}
>>>>
>>>> out:
>>>> 	spin_unlock_bh(&vvs->rx_lock);
>>>>
>>>> 	virtio_transport_send_credit_update(vsk);
>>>>
>>>> 	return dequeued_len;
>>>> }
>>> I think we can't do 'goto out' or break, because in case of error, 
>>> we still need
>>> to free packet.
>> Didn't we have code that remove packets from a previous message?
>> I don't see it anymore.
>>
>> For example if we have 10 packets queued for a message (the 10th 
>> packet
>> has the EOR flag) and the memcpy_to_msg() fails on the 2nd packet, with
>> you proposal we are freeing only the first 2 packets, the rest is there
>> and should be freed when reading the next message, but I don't see that
>> code.
>>
>> The same can happen if the recvmsg syscall is interrupted. In that case
>> we report that nothing was copied, but we freed the first N packets, so
>> they are lost but the other packets are still in the queue.
>>
>> Please check also the patch where we implemented
>> __vsock_seqpacket_recvmsg().
>>
>> I thinks we should free packets only when we are sure we copied them to
>> the user space.
>
>Hm, yes, this is problem. To solve it i can restore previous approach
>with seqbegin/seqend. In that case i can detect unfinished record and
>drop it's packets. Seems seqbegin will be a bit like 
>VIRTIO_VSOCK_SEQ_EOR in flags
>field of header(e.g. VIRTIO_VSOCK_SEQ_BEGIN). Message id and length are 
>unneeded,
>as channel considedered lossless. What do You think?
>

I think VIRTIO_VSOCK_SEQ_BEGIN is redundant, using only EOR should be 
fine.

When we receive EOR we know that this is the last packet on this message 
and the next packet will be the first of a new message.

What we should do is check that we have all the fragments of a packet 
and return them all together, otherwise we have to say we have nothing.

For example as we process packets from the vitqueue and queue them in 
the rx_queue we could use a counter of how many EORs are in the 
rx_queue, which we decrease in virtio_transport_seqpacket_do_dequeue() 
when we copied all the fragments.

If the counter is 0, we don't remove anything from the queue and 
virtio_transport_seqpacket_do_dequeue() returns 0.

So .seqpacket_dequeue should return 0 if there is not at least one 
complete message, or return the entire message. A partial message should 
never return.

What do you think?


Maybe we should start using skbuffs for seqpackets as well, but that 
might take some time, so that might be okay for now.

Thanks,
Stefano


  reply	other threads:[~2021-06-07 11:04 UTC|newest]

Thread overview: 49+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-20 19:13 [PATCH v10 00/18] virtio/vsock: introduce SOCK_SEQPACKET support Arseny Krasnov
2021-05-20 19:14 ` [PATCH v10 01/18] af_vsock: update functions for connectible socket Arseny Krasnov
2021-05-20 19:15 ` [PATCH v10 02/18] af_vsock: separate wait data loop Arseny Krasnov
2021-05-20 19:15 ` [PATCH v10 03/18] af_vsock: separate receive " Arseny Krasnov
2021-05-20 19:16 ` [PATCH v10 04/18] af_vsock: implement SEQPACKET receive loop Arseny Krasnov
2021-05-25 14:08   ` Stefano Garzarella
2021-06-04 15:06   ` Stefano Garzarella
2021-06-04 18:00     ` [MASSMAIL KLMS] " Arseny Krasnov
2021-06-07 10:48       ` Stefano Garzarella
2021-06-07 11:29         ` Arseny Krasnov
2021-06-07 12:28           ` Stefano Garzarella
2021-05-20 19:16 ` [PATCH v10 05/18] af_vsock: implement send logic for SEQPACKET Arseny Krasnov
2021-05-20 19:16 ` [PATCH v10 06/18] af_vsock: rest of SEQPACKET support Arseny Krasnov
2021-05-25 14:17   ` Stefano Garzarella
2021-05-20 19:16 ` [PATCH v10 07/18] af_vsock: update comments for stream sockets Arseny Krasnov
2021-05-20 19:17 ` [PATCH v10 08/18] virtio/vsock: set packet's type in virtio_transport_send_pkt_info() Arseny Krasnov
2021-05-20 19:17 ` [PATCH v10 09/18] virtio/vsock: simplify credit update function API Arseny Krasnov
2021-05-20 19:17 ` [PATCH v10 10/18] virtio/vsock: defines and constants for SEQPACKET Arseny Krasnov
2021-05-20 19:17 ` [PATCH v10 11/18] virtio/vsock: dequeue callback for SOCK_SEQPACKET Arseny Krasnov
2021-06-03 14:45   ` Stefano Garzarella
2021-06-04 13:12     ` Arseny Krasnov
2021-06-04 15:03       ` Stefano Garzarella
2021-06-04 18:03         ` Arseny Krasnov
2021-06-07 11:04           ` Stefano Garzarella [this message]
2021-06-07 13:18             ` Arseny Krasnov
2021-06-08  8:23               ` Stefano Garzarella
2021-06-08  9:40                 ` Arseny Krasnov
2021-06-08 10:19                   ` Stefano Garzarella
2021-06-08 10:24                     ` Arseny Krasnov
2021-06-08 10:39                       ` Stefano Garzarella
2021-05-20 19:18 ` [PATCH v10 12/18] virtio/vsock: add SEQPACKET receive logic Arseny Krasnov
2021-06-03 14:56   ` Stefano Garzarella
2021-05-20 19:18 ` [PATCH v10 13/18] virtio/vsock: rest of SOCK_SEQPACKET support Arseny Krasnov
2021-06-03 15:14   ` Stefano Garzarella
2021-05-20 19:18 ` [PATCH v10 14/18] virtio/vsock: enable SEQPACKET for transport Arseny Krasnov
2021-06-03 15:22   ` Stefano Garzarella
2021-05-20 19:19 ` [PATCH v10 15/18] vhost/vsock: support " Arseny Krasnov
2021-06-03 15:34   ` Stefano Garzarella
2021-06-04 13:13     ` Arseny Krasnov
2021-05-20 19:19 ` [PATCH v10 16/18] vsock/loopback: enable " Arseny Krasnov
2021-05-20 19:19 ` [PATCH v10 17/18] vsock_test: add SOCK_SEQPACKET tests Arseny Krasnov
2021-06-03 15:38   ` Stefano Garzarella
2021-05-20 19:20 ` [PATCH v10 18/18] virtio/vsock: update trace event for SEQPACKET Arseny Krasnov
2021-06-03 15:40   ` Stefano Garzarella
2021-05-21  7:55 ` [PATCH v10 00/18] virtio/vsock: introduce SOCK_SEQPACKET support Stefano Garzarella
2021-05-23 12:14   ` Arseny Krasnov
2021-05-25  8:22     ` Arseny Krasnov
2021-05-25 14:52       ` Stefano Garzarella
2021-05-26 12:16         ` Arseny 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=20210607110421.wkx4dj7wipwsqztj@steredhat \
    --to=sgarzare@redhat.com \
    --cc=andraprs@amazon.com \
    --cc=arseny.krasnov@kaspersky.com \
    --cc=colin.king@canonical.com \
    --cc=davem@davemloft.net \
    --cc=jasowang@redhat.com \
    --cc=jhansen@vmware.com \
    --cc=kuba@kernel.org \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mst@redhat.com \
    --cc=netdev@vger.kernel.org \
    --cc=nslusarek@gmx.net \
    --cc=oxffffaa@gmail.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).