linux-kernel - error returns from ->queue

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <20140211092904.GA6229@infradead.org>
Date:	Tue, 11 Feb 2014 01:29:04 -0800
From:	Christoph Hellwig <hch@...radead.org>
To:	Jens Axboe <axboe@...nel.dk>
Cc:	linux-kernel@...r.kernel.org, linux-scsi@...r.kernel.org
Subject: error returns from ->queue_rq

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.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/