[PATCH 1/3] block: copy multi iovec user mappings if QUEUE_FLAG_SG_GAPS is set

[hch@lst.de (Christoph Hellwig)]

On Thu, Jul 16, 2015@04:47:12PM +0000, Keith Busch wrote:
> On Wed, 15 Jul 2015, Sagi Grimberg wrote:
>> For drivers that don't support gaps in the SG lists handed to them we must
>> not create bios from multiple iovecs as they can be (and usually are)
>> discontiguous.  This doesn't matter for any current user, but will help
>> to allow iSER which can't handle gaps to use the QUEUE_FLAG_SG_GAPS flag
>> instead of using driver-local bounce buffering.
>
> Maybe SG_GAPS is a bit of a misnomer. There are cases we can directly
> map a user iov with multiple discontiguous vectors. At least for NVMe
> it'd work if each iov's base and length are on page boundaries, we don't
> need to do the indirect copy.

Yes, right now the check is a little pessimistic.  If we really care
for this use case we can iterate over all iovecs and check if they
would introduce offsets into a page.

Note that NVMe never uses blk_rq_map_user_iov with more than a single
iov so it doesn't apply there, there concern here is iSER, but the same
rules apply there as well.