From: Junnan Wu <junnan01.wu@samsung.com>
To: sgarzare@redhat.com
Cc: davem@davemloft.net, edumazet@google.com, eperezma@redhat.com,
horms@kernel.org, jasowang@redhat.com, junnan01.wu@samsung.com,
kuba@kernel.org, kvm@vger.kernel.org, lei19.wang@samsung.com,
linux-kernel@vger.kernel.org, mst@redhat.com,
netdev@vger.kernel.org, pabeni@redhat.com, q1.huang@samsung.com,
stefanha@redhat.com, virtualization@lists.linux.dev,
xuanzhuo@linux.alibaba.com, ying01.gao@samsung.com,
ying123.xu@samsung.com
Subject: Re: Re: [Patch net 1/2] vsock/virtio: initialize rx_buf_nr and rx_buf_max_nr when resuming
Date: Thu, 13 Feb 2025 09:28:05 +0800 [thread overview]
Message-ID: <20250213012805.2379064-1-junnan01.wu@samsung.com> (raw)
In-Reply-To: <gr5rqfwb4qgc23dadpfwe74jvsq37udpeqwhpokhnvvin6biv2@6v5npbxf6kbn>
>You need to update the title now that you're moving also queued_replies.
>
Well, I will update the title in V3 version.
>On Tue, Feb 11, 2025 at 03:19:21PM +0800, Junnan Wu wrote:
>>When executing suspend to ram twice in a row,
>>the `rx_buf_nr` and `rx_buf_max_nr` increase to three times vq->num_free.
>>Then after virtqueue_get_buf and `rx_buf_nr` decreased
>>in function virtio_transport_rx_work,
>>the condition to fill rx buffer
>>(rx_buf_nr < rx_buf_max_nr / 2) will never be met.
>>
>>It is because that `rx_buf_nr` and `rx_buf_max_nr`
>>are initialized only in virtio_vsock_probe(),
>>but they should be reset whenever virtqueues are recreated,
>>like after a suspend/resume.
>>
>>Move the `rx_buf_nr` and `rx_buf_max_nr` initialization in
>>virtio_vsock_vqs_init(), so we are sure that they are properly
>>initialized, every time we initialize the virtqueues, either when we
>>load the driver or after a suspend/resume.
>>At the same time, also move `queued_replies`.
>
>Why?
>
>As I mentioned the commit description should explain why the changes are
>being made for both reviewers and future references to this patch.
>
After your kindly remind, I have double checked all locations where `queued_replies`
used, and we think for order to prevent erroneous atomic load operations
on the `queued_replies` in the virtio_transport_send_pkt_work() function
which may disrupt the scheduling of vsock->rx_work
when transmitting reply-required socket packets,
this atomic variable must undergo synchronized initialization
alongside the preceding two variables after a suspend/resume.
If we reach agreement on it, I will add this description in V3 version.
BRs
Junnan Wu
>The rest LGTM.
>
>Stefano
>
>>
>>Fixes: bd50c5dc182b ("vsock/virtio: add support for device suspend/resume")
>>Co-developed-by: Ying Gao <ying01.gao@samsung.com>
>>Signed-off-by: Ying Gao <ying01.gao@samsung.com>
>>Signed-off-by: Junnan Wu <junnan01.wu@samsung.com>
>>---
>> net/vmw_vsock/virtio_transport.c | 10 +++++++---
>> 1 file changed, 7 insertions(+), 3 deletions(-)
>>
>>diff --git a/net/vmw_vsock/virtio_transport.c b/net/vmw_vsock/virtio_transport.c
>>index b58c3818f284..f0e48e6911fc 100644
>>--- a/net/vmw_vsock/virtio_transport.c
>>+++ b/net/vmw_vsock/virtio_transport.c
>>@@ -670,6 +670,13 @@ static int virtio_vsock_vqs_init(struct virtio_vsock *vsock)
>> };
>> int ret;
>>
>>+ mutex_lock(&vsock->rx_lock);
>>+ vsock->rx_buf_nr = 0;
>>+ vsock->rx_buf_max_nr = 0;
>>+ mutex_unlock(&vsock->rx_lock);
>>+
>>+ atomic_set(&vsock->queued_replies, 0);
>>+
>> ret = virtio_find_vqs(vdev, VSOCK_VQ_MAX, vsock->vqs, vqs_info, NULL);
>> if (ret < 0)
>> return ret;
>>@@ -779,9 +786,6 @@ static int virtio_vsock_probe(struct virtio_device *vdev)
>>
>> vsock->vdev = vdev;
>>
>>- vsock->rx_buf_nr = 0;
>>- vsock->rx_buf_max_nr = 0;
>>- atomic_set(&vsock->queued_replies, 0);
>>
>> mutex_init(&vsock->tx_lock);
>> mutex_init(&vsock->rx_lock);
>>--
>>2.34.1
>>
next prev parent reply other threads:[~2025-02-13 1:27 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CGME20250211071930epcas5p2dbb3a4171fbe04574c0fa7b3a6f1a0c2@epcas5p2.samsung.com>
2025-02-11 7:19 ` [Patch net 0/2] vsock suspend/resume fix Junnan Wu
2025-02-11 7:19 ` [Patch net 1/2] vsock/virtio: initialize rx_buf_nr and rx_buf_max_nr when resuming Junnan Wu
2025-02-11 8:57 ` Stefano Garzarella
2025-02-13 1:28 ` Junnan Wu [this message]
2025-02-13 9:25 ` Stefano Garzarella
2025-02-13 14:47 ` Stefano Garzarella
2025-02-14 1:02 ` Junnan Wu
2025-02-14 1:22 ` [Patch net v3] vsock/virtio: fix variables initialization during resuming Junnan Wu
2025-02-14 9:13 ` Luigi Leonardi
2025-02-14 12:17 ` Michael S. Tsirkin
2025-02-14 13:34 ` Stefano Garzarella
2025-02-15 4:00 ` patchwork-bot+netdevbpf
2025-02-11 7:19 ` [Patch net 2/2] vsock/virtio: Don't reset the created SOCKET during suspend to ram Junnan Wu
2025-02-11 8:49 ` Stefano Garzarella
2025-02-15 14:26 ` Markus Elfring
2025-02-11 8:54 ` [Patch net 0/2] vsock suspend/resume fix Stefano Garzarella
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=20250213012805.2379064-1-junnan01.wu@samsung.com \
--to=junnan01.wu@samsung.com \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=eperezma@redhat.com \
--cc=horms@kernel.org \
--cc=jasowang@redhat.com \
--cc=kuba@kernel.org \
--cc=kvm@vger.kernel.org \
--cc=lei19.wang@samsung.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mst@redhat.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=q1.huang@samsung.com \
--cc=sgarzare@redhat.com \
--cc=stefanha@redhat.com \
--cc=virtualization@lists.linux.dev \
--cc=xuanzhuo@linux.alibaba.com \
--cc=ying01.gao@samsung.com \
--cc=ying123.xu@samsung.com \
/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