[3/7] block: ensure bios return from blk_get_request are properly initialized
diff mbox

Message ID 1465924564-14503-4-git-send-email-hch@lst.de
State New
Headers show

Commit Message

Christoph Hellwig June 14, 2016, 5:16 p.m. UTC
blk_get_request is used for BLOCK_PC and similar passthrough requests.
Currently we always need to call blk_rq_set_block_pc or an open coded
version of it to allow appending bios using the request mapping helpers
later on, which is a somewhat awkward API.  Instead move the
initialization part of blk_rq_set_block_pc into blk_get_request, so that
we always have a safe to use request.

Signed-off-by: Christoph Hellwig <hch@lst.de>
---
 block/blk-core.c           | 13 ++++++++-----
 block/blk-mq.c             |  5 +++++
 drivers/block/virtio_blk.c |  1 -
 drivers/nvme/host/core.c   |  4 ----
 4 files changed, 13 insertions(+), 10 deletions(-)

Comments

Jens Axboe June 15, 2016, 9:02 a.m. UTC | #1
On 06/14/2016 07:16 PM, Christoph Hellwig wrote:
> blk_get_request is used for BLOCK_PC and similar passthrough requests.
> Currently we always need to call blk_rq_set_block_pc or an open coded
> version of it to allow appending bios using the request mapping helpers
> later on, which is a somewhat awkward API.  Instead move the
> initialization part of blk_rq_set_block_pc into blk_get_request, so that
> we always have a safe to use request.

This still puts the pc related memset() into the normal fast path...
Christoph Hellwig June 15, 2016, 10:07 a.m. UTC | #2
On Wed, Jun 15, 2016 at 11:02:18AM +0200, Jens Axboe wrote:
> On 06/14/2016 07:16 PM, Christoph Hellwig wrote:
>> blk_get_request is used for BLOCK_PC and similar passthrough requests.
>> Currently we always need to call blk_rq_set_block_pc or an open coded
>> version of it to allow appending bios using the request mapping helpers
>> later on, which is a somewhat awkward API.  Instead move the
>> initialization part of blk_rq_set_block_pc into blk_get_request, so that
>> we always have a safe to use request.
>
> This still puts the pc related memset() into the normal fast path...

Oops, I missed removing it from the alloc path when adding back
blk_rq_set_block_pc, will fix it up.

But I have to object to this actually being a fast path - it's not
used for any fs request, just BLOCK_PC, NVMe passthrough and various
driver specific little hacks.
--
To unsubscribe from this list: send the line "unsubscribe linux-block" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Jens Axboe June 15, 2016, 10:17 a.m. UTC | #3
On 06/15/2016 12:07 PM, Christoph Hellwig wrote:
> On Wed, Jun 15, 2016 at 11:02:18AM +0200, Jens Axboe wrote:
>> On 06/14/2016 07:16 PM, Christoph Hellwig wrote:
>>> blk_get_request is used for BLOCK_PC and similar passthrough requests.
>>> Currently we always need to call blk_rq_set_block_pc or an open coded
>>> version of it to allow appending bios using the request mapping helpers
>>> later on, which is a somewhat awkward API.  Instead move the
>>> initialization part of blk_rq_set_block_pc into blk_get_request, so that
>>> we always have a safe to use request.
>>
>> This still puts the pc related memset() into the normal fast path...
>
> Oops, I missed removing it from the alloc path when adding back
> blk_rq_set_block_pc, will fix it up.
>
> But I have to object to this actually being a fast path - it's not
> used for any fs request, just BLOCK_PC, NVMe passthrough and various
> driver specific little hacks.

I guess you are right, the fs path jumps in via 
__blk_mq_alloc_request(), so not fs fast path. But it'd still be nice to 
properly fix this. Can it wait until the rq->pc mess is resolved?
Christoph Hellwig June 15, 2016, 10:25 a.m. UTC | #4
On Wed, Jun 15, 2016 at 12:17:47PM +0200, Jens Axboe wrote:
> I guess you are right, the fs path jumps in via __blk_mq_alloc_request(), 
> so not fs fast path. But it'd still be nice to properly fix this. Can it 
> wait until the rq->pc mess is resolved?

I'll resend the series removing the memset in the blk_get_request path,
which I think is very useful for now as the requests currently returned
from blk_get_request / blk_mq_alloc_request are inherently dangerous.
req->cmd zeroing is really just a workaround broken devices in practice,
as spec complicant scsi device never should look at the cmd array
beyond the command length.

I'll try to expedite the pc_request split, but I'd really like to get
all the NVMe over Fabrics work in first, as we'd be in merge hell otherwise.
--
To unsubscribe from this list: send the line "unsubscribe linux-block" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Patch
diff mbox

diff --git a/block/blk-core.c b/block/blk-core.c
index c94c7ad..37852ec 100644
--- a/block/blk-core.c
+++ b/block/blk-core.c
@@ -1294,10 +1294,16 @@  static struct request *blk_old_get_request(struct request_queue *q, int rw,
 
 	spin_lock_irq(q->queue_lock);
 	rq = get_request(q, rw, 0, NULL, gfp_mask);
-	if (IS_ERR(rq))
+	if (IS_ERR(rq)) {
 		spin_unlock_irq(q->queue_lock);
-	/* q->queue_lock is unlocked at this point */
+		return rq;
+	}
 
+	/* q->queue_lock is unlocked at this point */
+	rq->__data_len = 0;
+	rq->__sector = (sector_t) -1;
+	rq->bio = rq->biotail = NULL;
+	memset(rq->__cmd, 0, sizeof(rq->__cmd));
 	return rq;
 }
 
@@ -1377,9 +1383,6 @@  EXPORT_SYMBOL(blk_make_request);
 void blk_rq_set_block_pc(struct request *rq)
 {
 	rq->cmd_type = REQ_TYPE_BLOCK_PC;
-	rq->__data_len = 0;
-	rq->__sector = (sector_t) -1;
-	rq->bio = rq->biotail = NULL;
 	memset(rq->__cmd, 0, sizeof(rq->__cmd));
 }
 EXPORT_SYMBOL(blk_rq_set_block_pc);
diff --git a/block/blk-mq.c b/block/blk-mq.c
index bc7166d..80dce26 100644
--- a/block/blk-mq.c
+++ b/block/blk-mq.c
@@ -263,6 +263,11 @@  struct request *blk_mq_alloc_request(struct request_queue *q, int rw,
 		blk_queue_exit(q);
 		return ERR_PTR(-EWOULDBLOCK);
 	}
+
+	rq->__data_len = 0;
+	rq->__sector = (sector_t) -1;
+	rq->bio = rq->biotail = NULL;
+	memset(rq->__cmd, 0, sizeof(rq->__cmd));
 	return rq;
 }
 EXPORT_SYMBOL(blk_mq_alloc_request);
diff --git a/drivers/block/virtio_blk.c b/drivers/block/virtio_blk.c
index 963a130..0be7dd6 100644
--- a/drivers/block/virtio_blk.c
+++ b/drivers/block/virtio_blk.c
@@ -243,7 +243,6 @@  static int virtblk_get_id(struct gendisk *disk, char *id_str)
 	req = blk_get_request(q, READ, GFP_KERNEL);
 	if (IS_ERR(req))
 		return PTR_ERR(req);
-	blk_rq_set_block_pc(req);
 	req->cmd_type = REQ_TYPE_DRV_PRIV;
 
 	err = blk_rq_map_kern(q, req, id_str, VIRTIO_BLK_ID_BYTES, GFP_KERNEL);
diff --git a/drivers/nvme/host/core.c b/drivers/nvme/host/core.c
index 9d7cee4..cb8ca1b 100644
--- a/drivers/nvme/host/core.c
+++ b/drivers/nvme/host/core.c
@@ -201,10 +201,6 @@  struct request *nvme_alloc_request(struct request_queue *q,
 
 	req->cmd_type = REQ_TYPE_DRV_PRIV;
 	req->cmd_flags |= REQ_FAILFAST_DRIVER;
-	req->__data_len = 0;
-	req->__sector = (sector_t) -1;
-	req->bio = req->biotail = NULL;
-
 	req->cmd = (unsigned char *)cmd;
 	req->cmd_len = sizeof(struct nvme_command);