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@xxxxxx> > 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 -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
