Re: [PATCH v2 2/2] scsi: bsg: map io_uring user buffers with GFP_KERNEL

On Mon, Jul 27, 2026 at 01:55:42AM +0000, sashiko-bot wrote:
> [Severity: High]
> This is a pre-existing issue, but does using GFP_KERNEL here cause a tag
> exhaustion deadlock?
>
> Prior to this call, scsi_alloc_request() consumes a hardware tag. If
> GFP_KERNEL enters direct reclaim and needs to write dirty pages back to the
> same block device, the filesystem will attempt to allocate another tag.
>
> If all tags are currently held by blocked BSG tasks, won't the system deadlock?

This is not introduced by this patch.

> [Severity: High]
> Does removing the GFP_NOWAIT fallback for the non-blocking io_uring issue
> path introduce a permanent task_work deadlock?
>
> If a user submits more than 256 IORING_OP_URING_CMD operations in a single
> batch, the bio allocations will exhaust the fs_bio_set mempool. By passing
> GFP_KERNEL to blk_rq_map_user_iov(), mempool_alloc() will put the submitter
> thread to sleep waiting for a bio to be freed.
>
> Since these bios are freed when their completions run via task_work
> (scsi_bsg_uring_task_cb), which must be executed by the very submitter thread
> now permanently blocked in mempool_alloc(), does this create an unresolvable
> circular dependency?

No. A large submit batch alone does not force mempool wait, and fs_bio_set
is shared — progress does not depend only on this task's task_work. This
matches the nvme io_uring passthrough path.

Thanks,
Yang Xiuwei