Re: [PATCH v7 05/12] nvdimm: virtio_pmem: use GFP_NOIO for flush requests

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] Dynamic allocations with `GFP_NOIO` on the block IO submission path without a mempool cause spurious IO failures under memory pressure.
--

commit 74fa63081d89bf3b9f9f1dec68f5b9b9595e7390
Author: Li Chen <me@linux.beauty>

nvdimm: virtio_pmem: use GFP_NOIO for flush requests
    
virtio_pmem_flush() can run from pmem_submit_bio() while filesystem IO
is waiting on the flush completion. The request object allocation can
sleep, but it should not enter filesystem or block IO reclaim from this
flush path.

> diff --git a/drivers/nvdimm/nd_virtio.c b/drivers/nvdimm/nd_virtio.c
> index 8e16b7780be1a..a35044afddf34 100644
> --- a/drivers/nvdimm/nd_virtio.c
> +++ b/drivers/nvdimm/nd_virtio.c
> @@ -61,7 +61,7 @@ static int virtio_pmem_flush(struct nd_region *nd_region)
>  		return -EIO;
>  	}
>  
> -	req_data = kmalloc_obj(*req_data);
> +	req_data = kmalloc_obj(*req_data, GFP_NOIO);

[Severity: High]
This is a pre-existing issue, but does this allocation lack a mempool?

Since this dynamically allocates memory on the block IO submission path
without a mempool, plain kmalloc with GFP_NOIO can fail under high
memory pressure because it does not wait indefinitely for reclaim.

When the allocation fails, virtio_pmem_flush() returns -ENOMEM, which
propagates up to pmem_submit_bio() as BLK_STS_RESOURCE. Since the block
layer does not retry BLK_STS_RESOURCE for bio-based drivers like pmem,
the error immediately propagates to the filesystem, potentially causing
unexpected data loss, read-only remounts, or journal aborts.

Should the request structure allocations here (and similarly in
async_pmem_flush()) be backed by a mempool_t to guarantee forward progress?

>  	if (!req_data)
>  		return -ENOMEM;
>

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260630092338.2094628-1-me@linux.beauty?part=5