From: Christoph Hellwig <hch@lst.de>
To: Jens Axboe <axboe@kernel.dk>
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, 5 Jan 2015 20:32:13 +0100 [thread overview]
Message-ID: <20150105193213.GA31955@lst.de> (raw)
In-Reply-To: <54AADF6A.6090100@kernel.dk>
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.
Signed-off-by: Christoph Hellwig <hch@lst.de>
---
drivers/scsi/scsi_lib.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
index 9ea95dd..6d5c0b8 100644
--- a/drivers/scsi/scsi_lib.c
+++ b/drivers/scsi/scsi_lib.c
@@ -591,7 +591,6 @@ static void scsi_free_sgtable(struct scsi_data_buffer *sdb, bool mq)
static int scsi_alloc_sgtable(struct scsi_data_buffer *sdb, int nents, bool mq)
{
struct scatterlist *first_chunk = NULL;
- gfp_t gfp_mask = mq ? GFP_NOIO : GFP_ATOMIC;
int ret;
BUG_ON(!nents);
@@ -606,7 +605,7 @@ static int scsi_alloc_sgtable(struct scsi_data_buffer *sdb, int nents, bool mq)
}
ret = __sg_alloc_table(&sdb->table, nents, SCSI_MAX_SG_SEGMENTS,
- first_chunk, gfp_mask, scsi_sg_alloc);
+ first_chunk, GFP_ATOMIC, scsi_sg_alloc);
if (unlikely(ret))
scsi_free_sgtable(sdb, mq);
return ret;
--
1.9.1
next prev parent reply other threads:[~2015-01-05 19:32 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 [this message]
2015-01-05 19:38 ` Jens Axboe
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=20150105193213.GA31955@lst.de \
--to=hch@lst.de \
--cc=JBottomley@parallels.com \
--cc=axboe@kernel.dk \
--cc=bvanassche@acm.org \
--cc=davej@redhat.com \
--cc=hare@suse.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.