From: "Michael S. Tsirkin" <mst@redhat.com>
To: Zhang Tianci <zhangtianci.1997@bytedance.com>
Cc: jasowang@redhat.com, xuanzhuo@linux.alibaba.com,
eperezma@redhat.com, marco.crivellari@suse.com,
anders.roxell@linaro.org, virtualization@lists.linux.dev,
linux-kernel@vger.kernel.org,
Xie Yongji <xieyongji@bytedance.com>
Subject: Re: [PATCH] vduse: Fix msg list race in vduse_dev_read_iter
Date: Fri, 30 Jan 2026 05:16:12 -0500 [thread overview]
Message-ID: <20260130050818-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <20260130081524.81271-1-zhangtianci.1997@bytedance.com>
Thanks for the patch! yet something to improve:
On Fri, Jan 30, 2026 at 04:15:24PM +0800, Zhang Tianci wrote:
> Move the message to recv_list before dropping msg_lock and copying the
> request to userspace, avoiding a transient unlinked state that can race
> with the msg_sync timeout path. Roll back to send_list on copy failures.
this is not how you write commit messages, though.
describe the problem then how you fix it, please.
something like:
if msg_sync timeout triggers after a message has been removed
from send_list and before it was added to
recv_list, then .... as a result ....
To fix, move the message ...
>
> Signed-off-by: Zhang Tianci <zhangtianci.1997@bytedance.com>
> Reviewed-by: Xie Yongji <xieyongji@bytedance.com>
> ---
> drivers/vdpa/vdpa_user/vduse_dev.c | 30 ++++++++++++++++++++++--------
> 1 file changed, 22 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/vdpa/vdpa_user/vduse_dev.c b/drivers/vdpa/vdpa_user/vduse_dev.c
> index ae357d014564c..b6a558341c06c 100644
> --- a/drivers/vdpa/vdpa_user/vduse_dev.c
> +++ b/drivers/vdpa/vdpa_user/vduse_dev.c
> @@ -325,6 +325,7 @@ static ssize_t vduse_dev_read_iter(struct kiocb *iocb, struct iov_iter *to)
> struct file *file = iocb->ki_filp;
> struct vduse_dev *dev = file->private_data;
> struct vduse_dev_msg *msg;
> + struct vduse_dev_request req;
> int size = sizeof(struct vduse_dev_request);
> ssize_t ret;
>
> @@ -339,7 +340,7 @@ static ssize_t vduse_dev_read_iter(struct kiocb *iocb, struct iov_iter *to)
>
> ret = -EAGAIN;
> if (file->f_flags & O_NONBLOCK)
> - goto unlock;
> + break;
>
> spin_unlock(&dev->msg_lock);
> ret = wait_event_interruptible_exclusive(dev->waitq,
> @@ -349,17 +350,30 @@ static ssize_t vduse_dev_read_iter(struct kiocb *iocb, struct iov_iter *to)
>
> spin_lock(&dev->msg_lock);
> }
> + if (!msg) {
> + spin_unlock(&dev->msg_lock);
> + return ret;
> + }
> +
> + memcpy(&req, &msg->req, sizeof(req));
> + /*
> + * Move @msg to recv_list before dropping msg_lock.
> + * This avoids a window where @msg is detached from any list and
> + * vduse_dev_msg_sync() timeout path may operate on an unlinked node.
> + */
when standing by itself, not as part of the patch, this
comment confuses more than it clarifies.
> + vduse_enqueue_msg(&dev->recv_list, msg);
> spin_unlock(&dev->msg_lock);
> - ret = copy_to_iter(&msg->req, size, to);
> - spin_lock(&dev->msg_lock);
> +
> + ret = copy_to_iter(&req, size, to);
> if (ret != size) {
> + spin_lock(&dev->msg_lock);
> + /* Roll back: move msg back to send_list if still pending. */
> + msg = vduse_find_msg(&dev->recv_list, req.request_id);
Looks like this always scans the whole list.
Make a variant using list_for_each_entry_reverse maybe?
> + if (msg)
> + vduse_enqueue_msg(&dev->send_list, msg);
why is it not a concern that it will be at the tail of the send_list now,
reordering the messages?
> + spin_unlock(&dev->msg_lock);
> ret = -EFAULT;
> - vduse_enqueue_msg(&dev->send_list, msg);
> - goto unlock;
> }
> - vduse_enqueue_msg(&dev->recv_list, msg);
> -unlock:
> - spin_unlock(&dev->msg_lock);
>
> return ret;
> }
> --
> 2.39.5
next prev parent reply other threads:[~2026-01-30 10:16 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-30 8:15 [PATCH] vduse: Fix msg list race in vduse_dev_read_iter Zhang Tianci
2026-01-30 10:16 ` Michael S. Tsirkin [this message]
2026-01-30 11:51 ` Eugenio Perez Martin
[not found] ` <CAP4dvscscRNbJBKwDLE-gebPT24fOJg08xap_0t00cPbYZ4xvQ@mail.gmail.com>
2026-02-02 9:28 ` [External] " Eugenio Perez Martin
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=20260130050818-mutt-send-email-mst@kernel.org \
--to=mst@redhat.com \
--cc=anders.roxell@linaro.org \
--cc=eperezma@redhat.com \
--cc=jasowang@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=marco.crivellari@suse.com \
--cc=virtualization@lists.linux.dev \
--cc=xieyongji@bytedance.com \
--cc=xuanzhuo@linux.alibaba.com \
--cc=zhangtianci.1997@bytedance.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 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.