[PATCH 1/2] loop: respect REQ_NOWAIT for memory allocation

[PATCH 1/2] loop: respect REQ_NOWAIT for memory allocation

[Chaitanya Kulkarni]

loop advertises REQ_NOWAIT support via BLK_FEAT_NOWAIT (set by
default for all blk-mq devices), but violates REQ_NOWAIT semantics
by using GFP_NOIO allocations which can block.

BLK_FEAT_NOWAIT is advertised through this call chain:
  loop_add()
   blk_mq_alloc_disk(&lim, ...)
    __blk_mq_alloc_disk()
     blk_mq_alloc_queue()
      lim->features |= BLK_FEAT_NOWAIT <-- Set by default for blk-mq

However, the REQ_NOWAIT I/O path violates this contract. For io_uring
inline submissions, the call chain is:

  1. Userspace (io_uring setup):
   io_uring_setup(entries, &params)
   fd = io_uring_register(IORING_REGISTER_FILES, &zloop_fd, 1)

  2. Userspace (submit I/O with NOWAIT):
   sqe = io_uring_get_sqe(ring)
   io_uring_prep_write(sqe, zloop_fd, buf, len, offset)
   io_uring_submit(ring)  <-- inline submission

  3. io_uring core (inline path):
   io_submit_sqes()
    io_submit_sqe()
     io_queue_sqe()
      issue_flags = IO_URING_F_NONBLOCK <-- Sets inline/nowait mode
      io_issue_sqe()
       io_write()
        if (force_nonblock)  <-- true for inline submission
         kiocb->ki_flags |= IOCB_NOWAIT

  4. VFS layer:
   call_write_iter()
    blkdev_write_iter()
     -> propagates IOCB_NOWAIT to REQ_NOWAIT on bio
     __blkdev_direct_IO_simple() OR
     __blkdev_direct_IO()        OR
     __blkdev_direct_IO_async()

  5. Block layer:
   blk_mq_submit_bio()
    blk_mq_get_new_requests()
     __blk_mq_alloc_requests()
      blk_mq_rq_ctx_init()
       -> propagates REQ_NOWAIT to request->cmd_flags
    __blk_mq_try_issue_directly() OR blk_mq_sched_insert_request()
     blk_mq_run_hw_queue()
      __blk_mq_delay_run_hw_queue()
       __blk_mq_run_hw_queue()
        blk_mq_sched_dispatch_requests()

  6. Loop driver:
   loop_queue_rq()
    lo_rw_aio()
     kmalloc_array(..., GFP_NOIO) <-- BLOCKS (REQ_NOWAIT violation)
      -> Should use GFP_NOWAIT when rq->cmd_flags & REQ_NOWAIT

Fix by using GFP_NOWAIT when REQ_NOWAIT is set, and return -EAGAIN
instead of -ENOMEM when NOWAIT allocation fails, allowing io_uring
to retry the operation with blocking allowed.

Signed-off-by: Chaitanya Kulkarni <ckulkarnilinux@gmail.com>
---
 drivers/block/loop.c | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/block/loop.c b/drivers/block/loop.c
index 13ce229d450c..bad61f41df34 100644
--- a/drivers/block/loop.c
+++ b/drivers/block/loop.c
@@ -350,6 +350,8 @@ static int lo_rw_aio(struct loop_device *lo, struct loop_cmd *cmd,
 	unsigned int offset;
 	int nr_bvec = 0;
 	int ret;
+	bool nowait = rq->cmd_flags & REQ_NOWAIT;
+	gfp_t alloc_flags = nowait ? GFP_NOWAIT : GFP_NOIO;
 
 	rq_for_each_bvec(tmp, rq, rq_iter)
 		nr_bvec++;
@@ -357,9 +359,9 @@ static int lo_rw_aio(struct loop_device *lo, struct loop_cmd *cmd,
 	if (rq->bio != rq->biotail) {
 
 		bvec = kmalloc_array(nr_bvec, sizeof(struct bio_vec),
-				     GFP_NOIO);
+				     alloc_flags);
 		if (!bvec)
-			return -EIO;
+			return nowait ? -EAGAIN : -ENOMEM;
 		cmd->bvec = bvec;
 
 		/*
-- 
2.40.0

[PATCH 2/2] zloop: respect REQ_NOWAIT for memory allocation

[Chaitanya Kulkarni]

zloop advertises REQ_NOWAIT support via BLK_FEAT_NOWAIT (set by
default for all blk-mq devices), but violates REQ_NOWAIT semantics
by using GFP_NOIO allocations which can block.

BLK_FEAT_NOWAIT is advertised through this call chain:
  zloop_add()
   blk_mq_alloc_disk(&lim, ...)
    __blk_mq_alloc_disk()
     blk_mq_alloc_queue()
      lim->features |= BLK_FEAT_NOWAIT <-- Set by default for blk-mq

However, the REQ_NOWAIT I/O path violates this contract. For io_uring
inline submissions, the call chain is:

  1. Userspace (io_uring setup):
   io_uring_setup(entries, &params)
   fd = io_uring_register(IORING_REGISTER_FILES, &zloop_fd, 1)

  2. Userspace (submit I/O with NOWAIT):
   sqe = io_uring_get_sqe(ring)
   io_uring_prep_write(sqe, zloop_fd, buf, len, offset)
   io_uring_submit(ring)  <-- inline submission

  3. io_uring core (inline path):
   io_submit_sqes()
    io_submit_sqe()
     io_queue_sqe()
      issue_flags = IO_URING_F_NONBLOCK <-- Sets inline/nowait mode
      io_issue_sqe()
       io_write()
        if (force_nonblock)  <-- true for inline submission
         kiocb->ki_flags |= IOCB_NOWAIT

  4. VFS layer:
   call_write_iter()
    blkdev_write_iter()
     -> propagates IOCB_NOWAIT to REQ_NOWAIT on bio
     __blkdev_direct_IO_simple() OR
     __blkdev_direct_IO()        OR
     __blkdev_direct_IO_async()

  5. Block layer:
   blk_mq_submit_bio()
    blk_mq_get_new_requests()
     __blk_mq_alloc_requests()
      blk_mq_rq_ctx_init()
       -> propagates REQ_NOWAIT to request->cmd_flags
    __blk_mq_try_issue_directly() OR blk_mq_sched_insert_request()
     blk_mq_run_hw_queue()
      __blk_mq_delay_run_hw_queue()
       __blk_mq_run_hw_queue()
        blk_mq_sched_dispatch_requests()

  6. Zloop driver:
   zloop_queue_rq()
    zloop_rw()
     kmalloc_array(..., GFP_NOIO) <-- BLOCKS (REQ_NOWAIT violation)
      -> Should use GFP_NOWAIT when rq->cmd_flags & REQ_NOWAIT

Fix by using GFP_NOWAIT when REQ_NOWAIT is set, and return -EAGAIN
instead of -ENOMEM when NOWAIT allocation fails, allowing io_uring
to retry the operation with blocking allowed.

Signed-off-by: Chaitanya Kulkarni <ckulkarnilinux@gmail.com>
---
 drivers/block/zloop.c | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/block/zloop.c b/drivers/block/zloop.c
index 92be9f0af00a..9295c4817bd4 100644
--- a/drivers/block/zloop.c
+++ b/drivers/block/zloop.c
@@ -372,6 +372,8 @@ static void zloop_rw(struct zloop_cmd *cmd)
 	sector_t zone_end;
 	int nr_bvec = 0;
 	int ret;
+	bool nowait = rq->cmd_flags & REQ_NOWAIT;
+	gfp_t alloc_flags = nowait ? GFP_NOWAIT : GFP_NOIO;
 
 	atomic_set(&cmd->ref, 2);
 	cmd->sector = sector;
@@ -443,9 +445,9 @@ static void zloop_rw(struct zloop_cmd *cmd)
 	if (rq->bio != rq->biotail) {
 		struct bio_vec *bvec;
 
-		cmd->bvec = kmalloc_array(nr_bvec, sizeof(*cmd->bvec), GFP_NOIO);
+		cmd->bvec = kmalloc_array(nr_bvec, sizeof(*cmd->bvec), alloc_flags);
 		if (!cmd->bvec) {
-			ret = -EIO;
+			ret = nowait ? -EAGAIN : -ENOMEM;
 			goto unlock;
 		}
 
-- 
2.40.0

Re: [PATCH 2/2] zloop: respect REQ_NOWAIT for memory allocation

[Damien Le Moal]

On 11/16/25 11:52, Chaitanya Kulkarni wrote:
>   6. Zloop driver:
>    zloop_queue_rq()
>     zloop_rw()
>      kmalloc_array(..., GFP_NOIO) <-- BLOCKS (REQ_NOWAIT violation)

Absolutely not. Please re-read the code and see that zloop_queue_rq() adds the
request (zloop command) to a workqueue and zloop_rw() is executed within the
work item context, that is, a different context from zloop_queue_rq.

So this patch is not necessary at all, there is no blocking violation as
zloop_queue_rq() never blocks.

>       -> Should use GFP_NOWAIT when rq->cmd_flags & REQ_NOWAIT



-- 
Damien Le Moal
Western Digital Research

Re: [PATCH 1/2] loop: respect REQ_NOWAIT for memory allocation

[Damien Le Moal]

On 11/16/25 11:52, Chaitanya Kulkarni wrote:
>   6. Loop driver:
>    loop_queue_rq()
>     lo_rw_aio()
>      kmalloc_array(..., GFP_NOIO) <-- BLOCKS (REQ_NOWAIT violation)
>       -> Should use GFP_NOWAIT when rq->cmd_flags & REQ_NOWAIT

Same comment as for zloop. Re-read the code and see that loop_queue_rq() calls
loop_queue_work(). That function has a memory allocation that is already marked
with GFP_NOWAIT, and that this function does not directly execute lo_rw_aio() as
that is done from loop_workfn(), in the work item context.
So again, no blocking violation that I can see here.
As far as I can tell, this patch is not needed.

-- 
Damien Le Moal
Western Digital Research

Re: [PATCH 1/2] loop: respect REQ_NOWAIT for memory allocation

[Chaitanya Kulkarni]

On 11/15/25 19:50, Damien Le Moal wrote:
> On 11/16/25 11:52, Chaitanya Kulkarni wrote:
>>    6. Loop driver:
>>     loop_queue_rq()
>>      lo_rw_aio()
>>       kmalloc_array(..., GFP_NOIO) <-- BLOCKS (REQ_NOWAIT violation)
>>        -> Should use GFP_NOWAIT when rq->cmd_flags & REQ_NOWAIT
> Same comment as for zloop. Re-read the code and see that loop_queue_rq() calls
> loop_queue_work(). That function has a memory allocation that is already marked
> with GFP_NOWAIT, and that this function does not directly execute lo_rw_aio() as
> that is done from loop_workfn(), in the work item context.
> So again, no blocking violation that I can see here.
> As far as I can tell, this patch is not needed.
>
Thanks for pointing that out. Since REQ_NOWAIT is not valid in the
workqueue, then REQ_NOWAIT flag needs to be cleared before
handing it over to workqueue ? is that the right interpretation?

e.g.

loop_queue_rq()
  loop_queue_work()
    ...
    ...
    rq->cmd_flags &= ~REQ_NOWAIT; <---
    
    list_add_tail(&cmd->list_entry, cmd_list);
    queue_work(lo->workqueue, work);
    spin_unlock_irq(&lo->lo_work_lock);

I have read the code [1] and the commit that added the flag [2] as well.
I could not find any mention of how switching to a workqueue context
affects the interpretation of REQ_NOWAIT, or whether its scope is
strictly limited to XXX_queue_rq() in the request lifecycle.

-ck

[1]

fio context =============>>

loop_queue_rq()
  loop_queue_work()
    queue_work(lo->workqueue, work);

fio ===> workqueue context

Work queue context =====>>>

loop_workfn
  loop_process_work
   loop_handle_cmd
    do_req_filebacked()

     struct request *rq = blk_mq_rq_from_pdu(cmd);

[2]

 From 03a07c92a9ed9938d828ca7f1d11b8bc63a7bb89 Mon Sep 17 00:00:00 2001
From: Goldwyn Rodrigues <rgoldwyn@suse.com>
Date: Tue, 20 Jun 2017 07:05:46 -0500
Subject: [PATCH] block: return on congested block device

A new bio operation flag REQ_NOWAIT is introduced to identify bio's
orignating from iocb with IOCB_NOWAIT. This flag indicates
to return immediately if a request cannot be made instead
of retrying.

Stacked devices such as md (the ones with make_request_fn hooks)
currently are not supported because it may block for housekeeping.
For example, an md can have a part of the device suspended.
For this reason, only request based devices are supported.
In the future, this feature will be expanded to stacked devices
by teaching them how to handle the REQ_NOWAIT flags.

Re: [PATCH 1/2] loop: respect REQ_NOWAIT for memory allocation

[Damien Le Moal]

On 11/16/25 14:43, Chaitanya Kulkarni wrote:
> On 11/15/25 19:50, Damien Le Moal wrote:
>> On 11/16/25 11:52, Chaitanya Kulkarni wrote:
>>>    6. Loop driver:
>>>     loop_queue_rq()
>>>      lo_rw_aio()
>>>       kmalloc_array(..., GFP_NOIO) <-- BLOCKS (REQ_NOWAIT violation)
>>>        -> Should use GFP_NOWAIT when rq->cmd_flags & REQ_NOWAIT
>> Same comment as for zloop. Re-read the code and see that loop_queue_rq() calls
>> loop_queue_work(). That function has a memory allocation that is already marked
>> with GFP_NOWAIT, and that this function does not directly execute lo_rw_aio() as
>> that is done from loop_workfn(), in the work item context.
>> So again, no blocking violation that I can see here.
>> As far as I can tell, this patch is not needed.
>>
> Thanks for pointing that out. Since REQ_NOWAIT is not valid in the
> workqueue, then REQ_NOWAIT flag needs to be cleared before
> handing it over to workqueue ? is that the right interpretation?

No. the queue_rq context does not block, so REQ_NOWAIT is being respected. I do
not see any issue with it. REQ_NOWAIT simply means that ->queue_rq() should not
block. It does not mean that the IO should/will be completed instantaneously...

Did you by any chance trigger a warning or something ? If yes, waht is the
reproducer ?

> 
> e.g.
> 
> loop_queue_rq()
>   loop_queue_work()
>     ...
>     ...
>     rq->cmd_flags &= ~REQ_NOWAIT; <---
>     
>     list_add_tail(&cmd->list_entry, cmd_list);
>     queue_work(lo->workqueue, work);
>     spin_unlock_irq(&lo->lo_work_lock);
> 
> I have read the code [1] and the commit that added the flag [2] as well.
> I could not find any mention of how switching to a workqueue context
> affects the interpretation of REQ_NOWAIT, or whether its scope is
> strictly limited to XXX_queue_rq() in the request lifecycle.
> 
> -ck
> 
> [1]
> 
> fio context =============>>
> 
> loop_queue_rq()
>   loop_queue_work()
>     queue_work(lo->workqueue, work);
> 
> fio ===> workqueue context
> 
> Work queue context =====>>>
> 
> loop_workfn
>   loop_process_work
>    loop_handle_cmd
>     do_req_filebacked()
> 
>      struct request *rq = blk_mq_rq_from_pdu(cmd);
> 
> [2]
> 
>  From 03a07c92a9ed9938d828ca7f1d11b8bc63a7bb89 Mon Sep 17 00:00:00 2001
> From: Goldwyn Rodrigues <rgoldwyn@suse.com>
> Date: Tue, 20 Jun 2017 07:05:46 -0500
> Subject: [PATCH] block: return on congested block device
> 
> A new bio operation flag REQ_NOWAIT is introduced to identify bio's
> orignating from iocb with IOCB_NOWAIT. This flag indicates
> to return immediately if a request cannot be made instead
> of retrying.
> 
> Stacked devices such as md (the ones with make_request_fn hooks)
> currently are not supported because it may block for housekeeping.
> For example, an md can have a part of the device suspended.
> For this reason, only request based devices are supported.
> In the future, this feature will be expanded to stacked devices
> by teaching them how to handle the REQ_NOWAIT flags.
> 


-- 
Damien Le Moal
Western Digital Research

Re: [PATCH 1/2] loop: respect REQ_NOWAIT for memory allocation

[Chaitanya Kulkarni]

On 11/15/25 22:26, Damien Le Moal wrote:
> On 11/16/25 14:43, Chaitanya Kulkarni wrote:
>> On 11/15/25 19:50, Damien Le Moal wrote:
>>> On 11/16/25 11:52, Chaitanya Kulkarni wrote:
>>>>     6. Loop driver:
>>>>      loop_queue_rq()
>>>>       lo_rw_aio()
>>>>        kmalloc_array(..., GFP_NOIO) <-- BLOCKS (REQ_NOWAIT violation)
>>>>         -> Should use GFP_NOWAIT when rq->cmd_flags & REQ_NOWAIT
>>> Same comment as for zloop. Re-read the code and see that loop_queue_rq() calls
>>> loop_queue_work(). That function has a memory allocation that is already marked
>>> with GFP_NOWAIT, and that this function does not directly execute lo_rw_aio() as
>>> that is done from loop_workfn(), in the work item context.
>>> So again, no blocking violation that I can see here.
>>> As far as I can tell, this patch is not needed.
>>>
>> Thanks for pointing that out. Since REQ_NOWAIT is not valid in the
>> workqueue, then REQ_NOWAIT flag needs to be cleared before
>> handing it over to workqueue ? is that the right interpretation?
> No. the queue_rq context does not block, so REQ_NOWAIT is being respected. I do
> not see any issue with it. REQ_NOWAIT simply means that ->queue_rq() should not
> block. It does not mean that the IO should/will be completed instantaneously...
>
> Did you by any chance trigger a warning or something ? If yes, waht is the
> reproducer ?

sorry for the late reply, yes I'm remotely debugging the loop device on
a physical machine, don't have any access to get the trace or reproducer.
While examining the request flags I encountered this, where req is still
marked REQ_NOWAIT and it's not honored.

-ck

Re: [PATCH 1/2] loop: respect REQ_NOWAIT for memory allocation

[hch]

On Sun, Nov 16, 2025 at 05:43:53AM +0000, Chaitanya Kulkarni wrote:
> On 11/15/25 19:50, Damien Le Moal wrote:
> > On 11/16/25 11:52, Chaitanya Kulkarni wrote:
> >>    6. Loop driver:
> >>     loop_queue_rq()
> >>      lo_rw_aio()
> >>       kmalloc_array(..., GFP_NOIO) <-- BLOCKS (REQ_NOWAIT violation)
> >>        -> Should use GFP_NOWAIT when rq->cmd_flags & REQ_NOWAIT
> > Same comment as for zloop. Re-read the code and see that loop_queue_rq() calls
> > loop_queue_work(). That function has a memory allocation that is already marked
> > with GFP_NOWAIT, and that this function does not directly execute lo_rw_aio() as
> > that is done from loop_workfn(), in the work item context.
> > So again, no blocking violation that I can see here.
> > As far as I can tell, this patch is not needed.
> >
> Thanks for pointing that out. Since REQ_NOWAIT is not valid in the
> workqueue, then REQ_NOWAIT flag needs to be cleared before
> handing it over to workqueue ? is that the right interpretation?

Having it cleared does seem useful as there is no need to skip blocking
operations.  I don't think it actually is required, just a lot more
efficient.

Re: [PATCH 1/2] loop: respect REQ_NOWAIT for memory allocation

[Jens Axboe]

On 11/17/25 10:21 PM, hch@lst.de wrote:
> On Sun, Nov 16, 2025 at 05:43:53AM +0000, Chaitanya Kulkarni wrote:
>> On 11/15/25 19:50, Damien Le Moal wrote:
>>> On 11/16/25 11:52, Chaitanya Kulkarni wrote:
>>>>    6. Loop driver:
>>>>     loop_queue_rq()
>>>>      lo_rw_aio()
>>>>       kmalloc_array(..., GFP_NOIO) <-- BLOCKS (REQ_NOWAIT violation)
>>>>        -> Should use GFP_NOWAIT when rq->cmd_flags & REQ_NOWAIT
>>> Same comment as for zloop. Re-read the code and see that loop_queue_rq() calls
>>> loop_queue_work(). That function has a memory allocation that is already marked
>>> with GFP_NOWAIT, and that this function does not directly execute lo_rw_aio() as
>>> that is done from loop_workfn(), in the work item context.
>>> So again, no blocking violation that I can see here.
>>> As far as I can tell, this patch is not needed.
>>>
>> Thanks for pointing that out. Since REQ_NOWAIT is not valid in the
>> workqueue, then REQ_NOWAIT flag needs to be cleared before
>> handing it over to workqueue ? is that the right interpretation?
> 
> Having it cleared does seem useful as there is no need to skip blocking
> operations.  I don't think it actually is required, just a lot more
> efficient.

Agree, it doesn't make any sense to carry the REQ_NOWAIT into a blocking
out-of-line submit.

-- 
Jens Axboe

Re: [PATCH 1/2] loop: respect REQ_NOWAIT for memory allocation

[Chaitanya Kulkarni]

On 11/18/25 05:57, Jens Axboe wrote:
> On 11/17/25 10:21 PM, hch@lst.de wrote:
>> On Sun, Nov 16, 2025 at 05:43:53AM +0000, Chaitanya Kulkarni wrote:
>>> On 11/15/25 19:50, Damien Le Moal wrote:
>>>> On 11/16/25 11:52, Chaitanya Kulkarni wrote:
>>>>>     6. Loop driver:
>>>>>      loop_queue_rq()
>>>>>       lo_rw_aio()
>>>>>        kmalloc_array(..., GFP_NOIO) <-- BLOCKS (REQ_NOWAIT violation)
>>>>>         -> Should use GFP_NOWAIT when rq->cmd_flags & REQ_NOWAIT
>>>> Same comment as for zloop. Re-read the code and see that loop_queue_rq() calls
>>>> loop_queue_work(). That function has a memory allocation that is already marked
>>>> with GFP_NOWAIT, and that this function does not directly execute lo_rw_aio() as
>>>> that is done from loop_workfn(), in the work item context.
>>>> So again, no blocking violation that I can see here.
>>>> As far as I can tell, this patch is not needed.
>>>>
>>> Thanks for pointing that out. Since REQ_NOWAIT is not valid in the
>>> workqueue, then REQ_NOWAIT flag needs to be cleared before
>>> handing it over to workqueue ? is that the right interpretation?
>> Having it cleared does seem useful as there is no need to skip blocking
>> operations.  I don't think it actually is required, just a lot more
>> efficient.
> Agree, it doesn't make any sense to carry the REQ_NOWAIT into a blocking
> out-of-line submit.
>
sent patches with clearing REQ_NOWAIT, please have a look.

-ck