From: Christoph Hellwig <hch@lst.de>
To: Jens Axboe <axboe@kernel.dk>
Cc: Christoph Hellwig <hch@lst.de>,
mst@redhat.com, ooo@electrozaur.com, nab@linux-iscsi.org,
linux-block@vger.kernel.org
Subject: Re: [PATCH 3/7] block: ensure bios return from blk_get_request are properly initialized
Date: Wed, 15 Jun 2016 12:25:18 +0200 [thread overview]
Message-ID: <20160615102518.GA16734@lst.de> (raw)
In-Reply-To: <57612B4B.90509@kernel.dk>
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.
next prev parent reply other threads:[~2016-06-15 10:25 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-06-14 17:15 a few passthrough request improvements V2 Christoph Hellwig
2016-06-14 17:15 ` [PATCH 1/7] memstick: don't allow REQ_TYPE_BLOCK_PC requests Christoph Hellwig
2016-06-14 17:15 ` [PATCH 2/7] virtio_blk: use blk_rq_map_kern Christoph Hellwig
2016-06-14 17:16 ` [PATCH 3/7] block: ensure bios return from blk_get_request are properly initialized Christoph Hellwig
2016-06-15 9:02 ` Jens Axboe
2016-06-15 10:07 ` Christoph Hellwig
2016-06-15 10:17 ` Jens Axboe
2016-06-15 10:25 ` Christoph Hellwig [this message]
2016-06-14 17:16 ` [PATCH 4/7] block: simplify and export blk_rq_append_bio Christoph Hellwig
2016-06-14 17:16 ` [PATCH 5/7] target: stop using blk_make_request Christoph Hellwig
2016-06-14 17:16 ` [PATCH 6/7] scsi/osd: open code blk_make_request Christoph Hellwig
2016-06-14 17:16 ` [PATCH 7/7] block: unexport various bio mapping helpers Christoph Hellwig
-- strict thread matches above, loose matches on Subject: below --
2016-07-19 9:31 resend: passthrough request improvements V3 Christoph Hellwig
2016-07-19 9:31 ` [PATCH 3/7] block: ensure bios return from blk_get_request are properly initialized Christoph Hellwig
2016-06-16 9:14 passthrough request improvements V3 Christoph Hellwig
2016-06-16 9:14 ` [PATCH 3/7] block: ensure bios return from blk_get_request are properly initialized Christoph Hellwig
2016-06-13 15:21 a few passthrough request improvements Christoph Hellwig
2016-06-13 15:21 ` [PATCH 3/7] block: ensure bios return from blk_get_request are properly initialized Christoph Hellwig
2016-06-14 2:17 ` Jens Axboe
2016-06-14 13:43 ` Christoph Hellwig
2016-06-14 15:04 ` Jens Axboe
2016-06-15 9:57 ` Boaz Harrosh
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20160615102518.GA16734@lst.de \
--to=hch@lst.de \
--cc=axboe@kernel.dk \
--cc=linux-block@vger.kernel.org \
--cc=mst@redhat.com \
--cc=nab@linux-iscsi.org \
--cc=ooo@electrozaur.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.