From: Ira Weiny <ira.weiny@intel.com>
To: Li Chen <me@linux.beauty>,
Dan Williams <dan.j.williams@intel.com>,
"Vishal Verma" <vishal.l.verma@intel.com>,
Dave Jiang <dave.jiang@intel.com>,
"Ira Weiny" <ira.weiny@intel.com>,
Pankaj Gupta <pankaj.gupta.linux@gmail.com>,
"Michael S. Tsirkin" <mst@redhat.com>,
Cornelia Huck <cohuck@redhat.com>,
Jakub Staron <jstaron@google.com>, <nvdimm@lists.linux.dev>,
<virtualization@lists.linux.dev>, <linux-kernel@vger.kernel.org>
Cc: Li Chen <me@linux.beauty>
Subject: Re: [PATCH] nvdimm: virtio_pmem: serialize flush requests
Date: Fri, 30 Jan 2026 14:52:12 -0600 [thread overview]
Message-ID: <697d19fc772ad_f6311008@iweiny-mobl.notmuch> (raw)
In-Reply-To: <20260113034552.62805-1-me@linux.beauty>
Li Chen wrote:
> Under heavy concurrent flush traffic, virtio-pmem can overflow its request
> virtqueue (req_vq): virtqueue_add_sgs() starts returning -ENOSPC and the
> driver logs "no free slots in the virtqueue". Shortly after that the
> device enters VIRTIO_CONFIG_S_NEEDS_RESET and flush requests fail with
> "virtio pmem device needs a reset".
>
> Serialize virtio_pmem_flush() with a per-device mutex so only one flush
> request is in-flight at a time. This prevents req_vq descriptor overflow
> under high concurrency.
>
> Reproducer (guest with virtio-pmem):
> - mkfs.ext4 -F /dev/pmem0
> - mount -t ext4 -o dax,noatime /dev/pmem0 /mnt/bench
> - fio: ioengine=io_uring rw=randwrite bs=4k iodepth=64 numjobs=64
> direct=1 fsync=1 runtime=30s time_based=1
I don't see this error.
<file>
13:28:50 > cat foo.fio
# test http://lore.kernel.org/20260113034552.62805-1-me@linux.beauty
[global]
filename=/mnt/bench/foo
ioengine=io_uring
size=1G
bs=4K
iodepth=64
numjobs=64
direct=1
fsync=1
runtime=30s
time_based=1
[rand-write]
rw=randwrite
</file>
It's possible I'm doing something wrong. Can you share your qemu cmdline
or more details on the bug yall see.
> - dmesg: "no free slots in the virtqueue"
> "virtio pmem device needs a reset"
>
> Fixes: 6e84200c0a29 ("virtio-pmem: Add virtio pmem driver")
> Signed-off-by: Li Chen <me@linux.beauty>
> ---
> drivers/nvdimm/nd_virtio.c | 15 +++++++++++----
> drivers/nvdimm/virtio_pmem.c | 1 +
> drivers/nvdimm/virtio_pmem.h | 4 ++++
> 3 files changed, 16 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/nvdimm/nd_virtio.c b/drivers/nvdimm/nd_virtio.c
> index c3f07be4aa22..827a17fe7c71 100644
> --- a/drivers/nvdimm/nd_virtio.c
> +++ b/drivers/nvdimm/nd_virtio.c
> @@ -44,19 +44,24 @@ static int virtio_pmem_flush(struct nd_region *nd_region)
> unsigned long flags;
> int err, err1;
>
> + might_sleep();
> + mutex_lock(&vpmem->flush_lock);
Assuming this does fix a bug I'd rather use guard here.
guard(mutex)(&vpmem->flush_lock);
Then skip all the gotos and out_unlock stuff.
Also, does this affect performance at all?
Ira
> +
> /*
> * Don't bother to submit the request to the device if the device is
> * not activated.
> */
> if (vdev->config->get_status(vdev) & VIRTIO_CONFIG_S_NEEDS_RESET) {
> dev_info(&vdev->dev, "virtio pmem device needs a reset\n");
> - return -EIO;
> + err = -EIO;
> + goto out_unlock;
> }
>
> - might_sleep();
> req_data = kmalloc(sizeof(*req_data), GFP_KERNEL);
> - if (!req_data)
> - return -ENOMEM;
> + if (!req_data) {
> + err = -ENOMEM;
> + goto out_unlock;
> + }
>
> req_data->done = false;
> init_waitqueue_head(&req_data->host_acked);
> @@ -103,6 +108,8 @@ static int virtio_pmem_flush(struct nd_region *nd_region)
> }
>
> kfree(req_data);
> +out_unlock:
> + mutex_unlock(&vpmem->flush_lock);
> return err;
> };
[snip]
next prev parent reply other threads:[~2026-01-30 20:49 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-13 3:45 [PATCH] nvdimm: virtio_pmem: serialize flush requests Li Chen
2026-01-30 20:52 ` Ira Weiny [this message]
2026-01-31 17:46 ` Michael S. Tsirkin
2026-02-01 4:40 ` Li Chen
2026-01-31 17:47 ` Michael S. Tsirkin
2026-02-02 17:18 ` Ira Weiny
2026-02-01 4:21 ` Li Chen
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=697d19fc772ad_f6311008@iweiny-mobl.notmuch \
--to=ira.weiny@intel.com \
--cc=cohuck@redhat.com \
--cc=dan.j.williams@intel.com \
--cc=dave.jiang@intel.com \
--cc=jstaron@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=me@linux.beauty \
--cc=mst@redhat.com \
--cc=nvdimm@lists.linux.dev \
--cc=pankaj.gupta.linux@gmail.com \
--cc=virtualization@lists.linux.dev \
--cc=vishal.l.verma@intel.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.