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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).