All of lore.kernel.org
 help / color / mirror / Atom feed
From: "hch@lst.de" <hch@lst.de>
To: Chaitanya Kulkarni <chaitanyak@nvidia.com>
Cc: Damien Le Moal <dlemoal@kernel.org>,
	Chaitanya Kulkarni <ckulkarnilinux@gmail.com>,
	"linux-block@vger.kernel.org" <linux-block@vger.kernel.org>,
	"axboe@kernel.dk" <axboe@kernel.dk>, "hch@lst.de" <hch@lst.de>
Subject: Re: [PATCH 1/2] loop: respect REQ_NOWAIT for memory allocation
Date: Tue, 18 Nov 2025 06:21:24 +0100	[thread overview]
Message-ID: <20251118052124.GA22100@lst.de> (raw)
In-Reply-To: <67472833-fd71-42a7-ac32-26e1da30f3ad@nvidia.com>

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.


  parent reply	other threads:[~2025-11-18  5:21 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-11-16  2:52 [PATCH 1/2] loop: respect REQ_NOWAIT for memory allocation Chaitanya Kulkarni
2025-11-16  2:52 ` [PATCH 2/2] zloop: " Chaitanya Kulkarni
2025-11-16  3:44   ` Damien Le Moal
2025-11-16  3:50 ` [PATCH 1/2] loop: " Damien Le Moal
2025-11-16  5:43   ` Chaitanya Kulkarni
2025-11-16  6:26     ` Damien Le Moal
2025-11-18  1:52       ` Chaitanya Kulkarni
2025-11-18  5:21     ` hch [this message]
2025-11-18 13:57       ` Jens Axboe
2025-11-19  0:39         ` Chaitanya Kulkarni

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20251118052124.GA22100@lst.de \
    --to=hch@lst.de \
    --cc=axboe@kernel.dk \
    --cc=chaitanyak@nvidia.com \
    --cc=ckulkarnilinux@gmail.com \
    --cc=dlemoal@kernel.org \
    --cc=linux-block@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.