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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
