From: Jens Axboe <axboe@kernel.dk>
To: Christoph Hellwig <hch@lst.de>
Cc: Sasha Levin <sasha.levin@oracle.com>,
bvanassche@acm.org, hare@suse.de, JBottomley@parallels.com,
linux-scsi@vger.kernel.org, LKML <linux-kernel@vger.kernel.org>,
Dave Jones <davej@redhat.com>
Subject: Re: scsi: non atomic allocation in mempool_alloc in atomic context
Date: Mon, 05 Jan 2015 12:38:04 -0700 [thread overview]
Message-ID: <54AAE81C.2080402@kernel.dk> (raw)
In-Reply-To: <20150105193213.GA31955@lst.de>
On 01/05/2015 12:32 PM, Christoph Hellwig wrote:
> On Mon, Jan 05, 2015 at 12:00:58PM -0700, Jens Axboe wrote:
>> That's not quite true, the only guarantee is that it WILL execute on the
>> CPU (or CPUs) that are set in the mask. So unless it ends up offloading
>> the run to a specific workqueue, we'll disable preempt in the current
>> path before ->queue_rq() is called.
>
> Oops. Indeed, with those recent changes ->queue_rq can't safely block
> for memory allocatios anymore.
>
> The patch below should fix it:
>
> ---
> From: Christoph Hellwig <hch@lst.de>
> Subject: scsi: ->queue_rq can't sleep
>
> Since Linux 3.19 blk-mq may disable preemption before calling into
> ->queue_rq, so we can't actually sleep anymore.
That was true in earlier kernels as well, going back a few versions at
least, preempt was disabled on calling __blk_mq_run_hw_queue(). Just
checked, and 3.16 and later have that as the behaviour. The only change
in 3.19 some shuffling around to avoid double preempt_disable in some
cases, it's now using get_cpu() and friends.
So we probably want do mark that as stable so we reach back to when
scsi-mq was added, unless the originally referenced patch getting rid of
the gfp_t mask didn't have the issue.
--
Jens Axboe
next prev parent reply other threads:[~2015-01-05 19:38 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-12-31 18:14 scsi: non atomic allocation in mempool_alloc in atomic context Sasha Levin
2014-12-31 19:56 ` Douglas Gilbert
2015-01-05 9:15 ` Christoph Hellwig
2015-01-05 15:17 ` Sasha Levin
2015-01-05 19:00 ` Jens Axboe
2015-01-05 19:32 ` Christoph Hellwig
2015-01-05 19:38 ` Jens Axboe [this message]
2015-01-05 19:42 ` Christoph Hellwig
-- strict thread matches above, loose matches on Subject: below --
2015-01-08 3:55 Alexei Starovoitov
2015-01-08 9:29 ` Christoph Hellwig
2015-01-08 20:31 Alexei Starovoitov
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=54AAE81C.2080402@kernel.dk \
--to=axboe@kernel.dk \
--cc=JBottomley@parallels.com \
--cc=bvanassche@acm.org \
--cc=davej@redhat.com \
--cc=hare@suse.de \
--cc=hch@lst.de \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=sasha.levin@oracle.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.