| Message ID | 1465924564-14503-4-git-send-email-hch@lst.de (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
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...
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
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?
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
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);
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(-)