[REGRESSION] commit b520c4eef83d ("block: split bio_alloc_bioset more clearly into a fast and slowpath") causes fsync to fail with pmem

[REGRESSION] commit b520c4eef83d ("block: split bio_alloc_bioset more clearly into a fast and slowpath") causes fsync to fail with pmem

[Sven-Hendrik Haase]

[-- Attachment #1.1.1: Type: text/plain, Size: 3275 bytes --]

Hey,

First of all, I don't do a lot of Linux development and so I hope that 
I'm submitting this issue to the right people and lists, please be gentle.

I noticed that starting with Linux 7.1, my pmem volumes inside of QEMU 
stopped working. My use case is this:

qemu-system-x86_64 ... tons of QEMU flags ...
-object 
memory-backend-file,id=pmem0,share=on,merge=on,discard-data=on,mem-path=/path/pmem0.pmem,size=100G
-device virtio-pmem-pci,memdev=pmem0,id=nv0

This used to work but inside the VM I'd get this when running mkfs.ext4 
/dev/pmem0 with guest kernel 7.1.3:

> [root@archlinux ~]# mkfs.ext4 /dev/pmem0
> mke2fs 1.47.4 (6-Mar-2025)
> Creating filesystem with 26214400 4k blocks and 6553600 inodes
> Filesystem UUID: 1a140446-43e6-4501-91db-cfaa250916e5
> Superblock backups stored on blocks: 
>     32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208, 
>     4096000, 7962624, 11239424, 20480000, 23887872
> 
> Allocating group tables: done                            
> Writing inode tables: done                            
> Creating journal (131072 blocks): done
> Writing superblocks and filesystem accounting information: mkfs.ext4: Input/output error while writing out and closing file system

I figured it must've been a recent regression since it worked until 
7.0.13 (the latest that I tested in the VM). I investigated a bit and 
was able to track it down to b520c4eef83d where some kind of refactor 
was committed. It seems to create the filesystem fine until the flush at 
the end. I did another test:

No fsync dd:

> [root@archlinux ~]# dd if=/dev/zero of=/dev/pmem0 bs=1M count=100           
> 100+0 records in
> 100+0 records out
> 104857600 bytes (105 MB, 100 MiB) copied, 0.195327 s, 537 MB/s

fsync dd:

> [root@archlinux ~]# dd if=/dev/zero of=/dev/pmem0 bs=1M count=100 conv=fsync
> dd: fsync failed for '/dev/pmem0': Input/output error
> 100+0 records in
> 100+0 records out
> 104857600 bytes (105 MB, 100 MiB) copied, 0.442089 s, 237 MB/s

Now, I'm entirely unfamiliar with the block subsystem in Linux but I 
poked at it a little and was able to produce a tiny patch that fixes 
this for me and I'm attaching it to this email as a discussion point. 
However, I'm not submitting it as an official patch because frankly I 
can't explain it well enough and I haven't done C in a long time, I just 
looked at the old logic and the new and put a bunch of debug prints all 
over the place. Basically this is just me doing my best to try to report 
this issue.

While scanning around, I noticed that just yesterday, a suspiciously 
similar topic was sent to the ML [0]. That patch is a lot bigger than 
mine, though. Also just when I was about to send this mail, I noticed 
[1] which seems to be exactly my issue.

All of this makes me even less confident in my patch since all of these 
patches are so much bigger and at least on the surface seem to tackle 
the same problem but maybe my report can add something here. If not, 
sorry for the noise.

#regzbot introduced: b520c4eef83d

[0] 
https://lore.kernel.org/lkml/20260709124455.1547912-1-joseph.qi@linux.alibaba.com/
[1] https://lore.kernel.org/lkml/20260630092338.2094628-1-me@linux.beauty/

[-- Attachment #1.1.2: bio.patch --]
[-- Type: text/x-patch, Size: 392 bytes --]

diff --git a/block/bio.c b/block/bio.c
index 5f10900b3f42..9a94b45135b7 100644
--- a/block/bio.c
+++ b/block/bio.c
@@ -555,6 +555,8 @@ struct bio *bio_alloc_bioset(struct block_device *bdev, unsigned short nr_vecs,
 		bio = bio_alloc_percpu_cache(bs);
 	} else {
 		opf &= ~REQ_ALLOC_CACHE;
+	}
+	if (!bio) {
 		p = kmem_cache_alloc(bs->bio_slab, gfp);
 		if (p)
 			bio = p + bs->front_pad;

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]

Re: [REGRESSION] commit b520c4eef83d ("block: split bio_alloc_bioset more clearly into a fast and slowpath") causes fsync to fail with pmem

[Keith Busch]

On Fri, Jul 10, 2026 at 08:07:32PM +0200, Sven-Hendrik Haase wrote:
> I noticed that starting with Linux 7.1, my pmem volumes inside of QEMU
> stopped working. My use case is this:
> 
> qemu-system-x86_64 ... tons of QEMU flags ...
> -object memory-backend-file,id=pmem0,share=on,merge=on,discard-data=on,mem-path=/path/pmem0.pmem,size=100G
> -device virtio-pmem-pci,memdev=pmem0,id=nv0
> 
> This used to work but inside the VM I'd get this when running mkfs.ext4
> /dev/pmem0 with guest kernel 7.1.3:

This pending fix (which is the same as what you proposed here) should
take care of it:

https://lore.kernel.org/linux-block/20260709020145.4011533-1-joseph.qi@linux.alibaba.com/

Re: [REGRESSION] commit b520c4eef83d ("block: split bio_alloc_bioset more clearly into a fast and slowpath") causes fsync to fail with pmem

[Sven-Hendrik Haase]

[-- Attachment #1.1: Type: text/plain, Size: 872 bytes --]



On 10.07.26 20:17, Keith Busch wrote:
> On Fri, Jul 10, 2026 at 08:07:32PM +0200, Sven-Hendrik Haase wrote:
>> I noticed that starting with Linux 7.1, my pmem volumes inside of QEMU
>> stopped working. My use case is this:
>>
>> qemu-system-x86_64 ... tons of QEMU flags ...
>> -object memory-backend-file,id=pmem0,share=on,merge=on,discard-data=on,mem-path=/path/pmem0.pmem,size=100G
>> -device virtio-pmem-pci,memdev=pmem0,id=nv0
>>
>> This used to work but inside the VM I'd get this when running mkfs.ext4
>> /dev/pmem0 with guest kernel 7.1.3:
> 
> This pending fix (which is the same as what you proposed here) should
> take care of it:
> 
> https://lore.kernel.org/linux-block/20260709020145.4011533-1-joseph.qi@linux.alibaba.com/

Oh, indeed. That's the very same patch. Well, looks like it's in the 
queue, then.

Sorry for the noise. :)

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]