> On 7/9/26 12:24 AM, Christoph Hellwig wrote:
> > On Wed, Jul 08, 2026 at 08:42:38PM +0800, Joseph Qi wrote:
> >> diff --git a/drivers/nvdimm/nd_virtio.c b/drivers/nvdimm/nd_virtio.c
> >> index 4176046627beb..081370aac6317 100644
> >> --- a/drivers/nvdimm/nd_virtio.c
> >> +++ b/drivers/nvdimm/nd_virtio.c
> >> @@ -117,7 +117,7 @@ int async_pmem_flush(struct nd_region *nd_region,
> >> struct bio *bio)
> >> if (bio && bio->bi_iter.bi_sector != -1) {
> >> struct bio *child = bio_alloc(bio->bi_bdev, 0,
> >> REQ_OP_WRITE | REQ_PREFLUSH,
> >> - GFP_ATOMIC);
> >> + GFP_NOIO);
> >>
> >> if (!child)
> >> return -ENOMEM;
> >
> > This NULL check can go away now, and probaby should to avoid confusion.
> >
> > Also bio_alloc allocates from fs_bio_set, so if the incoming bio
> > is from that, we can still deadlock. We'll need a separate bio_set
> > for this to be deadlock free. disk->bio_split isn't otherwise
> > used for the drivers/nvdimm/ driverss, so you might be able to
> > repurpose that if you want to be creative.
>
> Thanks for pointing this out.
>
> Seems it is more proper to use a driver-private bio_set instead of
> repurposing bd_disk->bio_split, like raid5-ppl flush_bs.
>
> Pankaj, what's your opinion?
Hi Joseph,
Thank you for the patch!
I am not very familiar with the internals of fs_bio_set, so I do not
have a strong opinion on the implementation details. However, a
driver-private bio_set sounds reasonable to me, and I would go with
Christoph's suggestion.
Best regards,
Pankaj
>
> Thanks,
> Joseph
