Re: [PATCH v6 04/12] nvdimm: virtio_pmem: stop allocating child flush bio

[Li Chen <me@linux.beauty>]

Hi Pankaj

 ---- On Thu, 25 Jun 2026 01:22:14 +0800  Pankaj Gupta <pankaj.gupta.linux@gmail.com> wrote --- 
 > > pmem_submit_bio() passes the parent bio to nvdimm_flush() for
 > > REQ_FUA. For virtio-pmem this makes async_pmem_flush() allocate
 > > and submit a child PREFLUSH bio chained to the parent.
 > >
 > > That child allocation is in the block submit path. Making it
 > > blocking with GFP_NOIO can consume the same global bio mempool that
 > > submit_bio() uses, while making it GFP_ATOMIC can fail under
 > > pressure. A forced failure of the child allocation produced:
 > >
 > > virtio_pmem: forcing child bio allocation failure for test
 > > Buffer I/O error on dev pmem0, logical block 0, lost sync page write
 > > EXT4-fs (pmem0): I/O error while writing superblock
 > > EXT4-fs (pmem0): mount failed
 > >
 > > Avoid the child bio completely. Flush FUA synchronously, like
 > > REQ_PREFLUSH, then complete the parent after the flush. Since no
 > > child bio can be created, async_pmem_flush() now only issues the
 > > virtio flush and preserves negative errno values.
 > 
 > Child flush is asynchronous (performs async flush to host side and returns).
 > Till child bio completes guest userspace waits in pending IO state.
 > It seems the current change will affect the behavior?
 > 
 > Prior RFC [1] attempted to coalesce the async FLUSH request between guest &host.
 > If there is interest, that approach could be revisited or integrated here?
 > 
 > [1] https://lore.kernel.org/all/20220111161937.56272-1-pankaj.gupta.linux@gmail.com/#t


Yes, agreed. This does change the FUA path.

I will rework it to avoid the child bio allocation while keeping the
parent bio completion asynchronous, using your RFC as reference.

Regards,
Li​