Hi Ira,
On Sat, 31 Jan 2026 04:52:12 +0800, Ira Weiny wrote: > > 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/[email protected] > > [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. Thanks for taking a look. I can reproduce the issue here, but it is timing dependent. A single fio run does not always hit it, so I suspect that's why you're not seeing the dmesg messages. Environment: QEMU: 10.1.2 virtio-pmem backend: memory-backend-ram (shared) The virtio-pmem relevant QEMU bits: -object memory-backend-ram,id=pmem0,size=10G,share=on -device virtio-pmem-pci,id=virtio-pmem0,memdev=pmem0 For completeness, this is the full QEMU command line I used (paths replaced with placeholders): qemu-system-x86_64 -enable-kvm -cpu host -smp 16 -m 10G,maxmem=20G \\ -netdev user,id=net0,hostfwd=tcp::<ssh_port>-:22 \\ -device virtio-net,netdev=net0 \\ -drive file=<guest.qcow2>,if=none,id=boot0,format=qcow2 \\ -device virtio-blk-pci,drive=boot0,num-queues=4 \\ -object memory-backend-ram,id=pmem0,size=10G,share=on \\ -device virtio-pmem-pci,id=virtio-pmem0,memdev=pmem0 \\ -nographic -kernel <bzImage> -append "<cmdline>" Kernel under test (baseline, no patch): v6.18-764-g7aa104c7e8e9 I used the same fio parameters from the cover letter. The only difference is that I run it in a loop so it has multiple chances to trigger. Each iteration does a fresh mkfs + mount and clears dmesg before running fio: This should be equivalent to the foo.fio you posted. for i in $(seq 1 10); do umount -l /mnt/bench 2>/dev/null || true mkfs.ext4 -F /dev/pmem0 mkdir -p /mnt/bench dmesg -C mount -t ext4 -o dax,noatime /dev/pmem0 /mnt/bench fio --name=randwrite_fsync --filename=/mnt/bench/foo --size=1G \\ --ioengine=io_uring --rw=randwrite --bs=4k --iodepth=64 --numjobs=64 \\ --direct=1 --fsync=1 --runtime=30 --time_based=1 dmesg | egrep -i \\ -e "no free slots in the virtqueue" \\ -e "virtio pmem device needs a reset" && break done If it does not trigger in 10 iterations, reboot the guest and repeat. On the baseline kernel, I see: "failed to send command to virtio pmem device, no free slots in the virtqueue" and "virtio pmem device needs a reset" Typically within a few iterations (often on the first one). With the fix applied, I ran 10 iterations back-to-back and did not see the above messages. > > - 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 <[email protected]> > > --- > > 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. Agreed. I'll use guard in v2. > Also, does this affect performance at all? I did a quick sanity check. With a smaller numjobs value (numjobs=16, iodepth=64, fsync=1, bs=4k, runtime=30s), I did not see a regression on this setup. At numjobs=64 the baseline frequently hits NEEDS_RESET, so correctness is the primary motivation here. Regards, Li
