All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jens Axboe <jens.axboe@oracle.com>
To: "Chen, Kenneth W" <kenneth.w.chen@intel.com>
Cc: linux-kernel@vger.kernel.org, dm-devel@redhat.com,
	mchristi@redhat.com, agk@redhat.com
Subject: Re: [RFC PATCH 1/8] rqbased-dm: allow blk_get_request() to be called from interrupt context
Date: Wed, 20 Dec 2006 20:17:33 +0100	[thread overview]
Message-ID: <20061220191730.GL10535@kernel.dk> (raw)
In-Reply-To: <000001c7246a$ae31c8a0$ff0da8c0@amr.corp.intel.com>

On Wed, Dec 20 2006, Chen, Kenneth W wrote:
> Kiyoshi Ueda wrote on Wednesday, December 20, 2006 9:50 AM
> > On Wed, 20 Dec 2006 14:48:49 +0100, Jens Axboe <jens.axboe@oracle.com> wrote:
> > > Big NACK on this - it's not only really ugly, it's also buggy to pass
> > > interrupt flags as function arguments. As you also mention in the 0/1
> > > mail, this also breaks CFQ.
> > > 
> > > Why do you need in-interrupt request allocation?
> >  
> > Because I'd like to use blk_get_request() in q->request_fn()
> > which can be called from interrupt context like below:
> >   scsi_io_completion -> scsi_end_request -> scsi_next_command
> >   -> scsi_run_queue -> blk_run_queue -> q->request_fn
> > 
> > [ ...]
> > 
> > Do you think creating another function like blk_get_request_nowait()
> > is acceptable?
> 
> You don't need to create another function.  blk_get_request already
> have both wait and nowait semantics via gfp_mask argument. If you can
> not block, then clear __GFP_WAIT bit in the mask before calling
> blk_get_request.

Doesn't work, get_request() assumes that the caller grabbed the queue
lock and disabled interrupts, and does an unconditionaly

        spin_unlock_irq()

inside it. So you can NEVER use get_request() for even GFP_ATOMIC
allocations, as it assumes the original context was a process context.

-- 
Jens Axboe

WARNING: multiple messages have this Message-ID (diff)
From: Jens Axboe <jens.axboe@oracle.com>
To: "Chen, Kenneth W" <kenneth.w.chen@intel.com>
Cc: "'Kiyoshi Ueda'" <k-ueda@ct.jp.nec.com>,
	agk@redhat.com, mchristi@redhat.com,
	linux-kernel@vger.kernel.org, dm-devel@redhat.com,
	j-nomura@ce.jp.nec.com
Subject: Re: [RFC PATCH 1/8] rqbased-dm: allow blk_get_request() to be called from interrupt context
Date: Wed, 20 Dec 2006 20:17:33 +0100	[thread overview]
Message-ID: <20061220191730.GL10535@kernel.dk> (raw)
In-Reply-To: <000001c7246a$ae31c8a0$ff0da8c0@amr.corp.intel.com>

On Wed, Dec 20 2006, Chen, Kenneth W wrote:
> Kiyoshi Ueda wrote on Wednesday, December 20, 2006 9:50 AM
> > On Wed, 20 Dec 2006 14:48:49 +0100, Jens Axboe <jens.axboe@oracle.com> wrote:
> > > Big NACK on this - it's not only really ugly, it's also buggy to pass
> > > interrupt flags as function arguments. As you also mention in the 0/1
> > > mail, this also breaks CFQ.
> > > 
> > > Why do you need in-interrupt request allocation?
> >  
> > Because I'd like to use blk_get_request() in q->request_fn()
> > which can be called from interrupt context like below:
> >   scsi_io_completion -> scsi_end_request -> scsi_next_command
> >   -> scsi_run_queue -> blk_run_queue -> q->request_fn
> > 
> > [ ...]
> > 
> > Do you think creating another function like blk_get_request_nowait()
> > is acceptable?
> 
> You don't need to create another function.  blk_get_request already
> have both wait and nowait semantics via gfp_mask argument. If you can
> not block, then clear __GFP_WAIT bit in the mask before calling
> blk_get_request.

Doesn't work, get_request() assumes that the caller grabbed the queue
lock and disabled interrupts, and does an unconditionaly

        spin_unlock_irq()

inside it. So you can NEVER use get_request() for even GFP_ATOMIC
allocations, as it assumes the original context was a process context.

-- 
Jens Axboe


  reply	other threads:[~2006-12-20 19:17 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-12-19 22:11 [RFC PATCH 1/8] rqbased-dm: allow blk_get_request() to be called from interrupt context Kiyoshi Ueda
2006-12-19 22:11 ` Kiyoshi Ueda
2006-12-20 13:48 ` Jens Axboe
2006-12-20 13:48   ` Jens Axboe
2006-12-20 17:50   ` Kiyoshi Ueda
2006-12-20 17:50     ` Kiyoshi Ueda
2006-12-20 18:49     ` Jens Axboe
2006-12-20 18:49       ` Jens Axboe
2006-12-20 21:55       ` Kiyoshi Ueda
2006-12-20 21:55         ` Kiyoshi Ueda
2006-12-21  7:53         ` Jens Axboe
2006-12-21  7:53           ` Jens Axboe
2006-12-21 17:59           ` Mike Christie
2006-12-21 17:59             ` [dm-devel] " Mike Christie
2006-12-21 18:13             ` Mike Christie
2006-12-21 18:13               ` [dm-devel] " Mike Christie
2006-12-21 18:24               ` Jens Axboe
2006-12-21 18:24                 ` [dm-devel] " Jens Axboe
2006-12-21 18:30                 ` Mike Christie
2006-12-21 18:30                   ` [dm-devel] " Mike Christie
2006-12-21 18:36                   ` Mike Christie
2006-12-21 18:36                     ` [dm-devel] " Mike Christie
2006-12-21 18:42                     ` Jens Axboe
2006-12-21 18:42                       ` [dm-devel] " Jens Axboe
2006-12-21 18:57                       ` Mike Christie
2006-12-21 18:57                         ` [dm-devel] " Mike Christie
2006-12-21 19:19                         ` Jens Axboe
2006-12-21 19:19                           ` [dm-devel] " Jens Axboe
2006-12-21 22:22                           ` Mike Christie
2006-12-21 22:22                             ` [dm-devel] " Mike Christie
2006-12-21 18:40                   ` Jens Axboe
2006-12-21 18:40                     ` [dm-devel] " Jens Axboe
2006-12-21 18:11           ` Kiyoshi Ueda
2006-12-21 18:11             ` Kiyoshi Ueda
2006-12-21 18:21             ` Jens Axboe
2006-12-21 18:21               ` Jens Axboe
2006-12-20 19:11     ` Chen, Kenneth W
2006-12-20 19:11       ` Chen, Kenneth W
2006-12-20 19:17       ` Jens Axboe [this message]
2006-12-20 19:17         ` Jens Axboe
2006-12-22 14:01     ` Christoph Hellwig
2006-12-22 14:01       ` Christoph Hellwig
2006-12-22 17:32       ` Jens Axboe

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=20061220191730.GL10535@kernel.dk \
    --to=jens.axboe@oracle.com \
    --cc=agk@redhat.com \
    --cc=dm-devel@redhat.com \
    --cc=kenneth.w.chen@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mchristi@redhat.com \
    /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.