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

From: Li Chen

Date: Sat Jun 27 2026 - 08:44:30 EST


Hi Pankaj

---- On Thu, 25 Jun 2026 01:22:14 +0800 Pankaj Gupta <pankaj.gupta.linux@xxxxxxxxx> 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@xxxxxxxxx/#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​