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

[Chaitanya Kulkarni <chaitanyak@nvidia.com>]

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