On 7/9/26 6:58 PM, Pankaj Gupta wrote:
>> 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.
>
Fine, I'll send out v2 later to address this.
Thanks,
Joseph
