public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
* error returns from ->queue_rq
@ 2014-02-11  9:29 Christoph Hellwig
  2014-02-11 15:44 ` Jens Axboe
  0 siblings, 1 reply; 2+ messages in thread
From: Christoph Hellwig @ 2014-02-11  9:29 UTC (permalink / raw)
  To: Jens Axboe; +Cc: linux-kernel, linux-scsi

Hi Jens,

seems like with the SCSI work I introduced the first
BLK_MQ_RQ_QUEUE_ERROR error return in the tree, and immediately ran into
the first pitfall.  The code as-is expects rq->errors set to an error
value, which otherwise is an  internal field used by the block layer and
some drivers, but not part of the communication protocol between the
two.

We can either make it part of the protocol for blk-mq, which would
require documenting and praying driver writers get it right, or
alternatively we could map BLK_MQ_RQ_QUEUE_ERROR to -EIO and if
nessecary introduce other return values if we need to return other
errors.  The third option would be to remove BLK_MQ_RQ_QUEUE_ERROR
entirely and require drivers to call blk_mq_end_io themselves from
->queue_rq, mirroring the ->queuecommand error handling.  I'm undecided
between options 2 and 3, but I'd rather avoid the current pitfall.

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: error returns from ->queue_rq
  2014-02-11  9:29 error returns from ->queue_rq Christoph Hellwig
@ 2014-02-11 15:44 ` Jens Axboe
  0 siblings, 0 replies; 2+ messages in thread
From: Jens Axboe @ 2014-02-11 15:44 UTC (permalink / raw)
  To: Christoph Hellwig; +Cc: linux-kernel, linux-scsi

On Tue, Feb 11 2014, Christoph Hellwig wrote:
> Hi Jens,
> 
> seems like with the SCSI work I introduced the first
> BLK_MQ_RQ_QUEUE_ERROR error return in the tree, and immediately ran into
> the first pitfall.  The code as-is expects rq->errors set to an error
> value, which otherwise is an  internal field used by the block layer and
> some drivers, but not part of the communication protocol between the
> two.
> 
> We can either make it part of the protocol for blk-mq, which would
> require documenting and praying driver writers get it right, or
> alternatively we could map BLK_MQ_RQ_QUEUE_ERROR to -EIO and if
> nessecary introduce other return values if we need to return other
> errors.  The third option would be to remove BLK_MQ_RQ_QUEUE_ERROR
> entirely and require drivers to call blk_mq_end_io themselves from
> ->queue_rq, mirroring the ->queuecommand error handling.  I'm undecided
> between options 2 and 3, but I'd rather avoid the current pitfall.

Lets go for option #2. I agree that we should not make this a new
depedency, it's a lot more robust to just have it be -EIO and add other
error returns as needed.

-- 
Jens Axboe


^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2014-02-11 15:44 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2014-02-11  9:29 error returns from ->queue_rq Christoph Hellwig
2014-02-11 15:44 ` Jens Axboe

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox