Re: [PATCH] block: streamline meta bounce buffer handling

[Christoph Hellwig <hch@lst.de>]

On Mon, May 06, 2024 at 02:36:06PM -0600, Keith Busch wrote:
> Unlike blk-map, the integrity user buffer will fallback to a copy if the
> ubuf has too many segments, where blk_rq_map_user() fails with EINVAL.
> 
> For user integrity, we have to pin the buffer anyway to get the true
> segment count and check against the queue limits, so the copy to/from
> takes advantage of that needed pin.

Can we document that somewhere please?

> That EINVAL has been the source of a lot of "bugs" where we have to
> explain why huge pages are necessary for largish (>512k) transfer nvme
> passthrough commands. It might be a nice feature if blk_rq_map_user()
> behaved like blk_integrity_map_user() for that condition.

Who wants to sign up for it?  If we also clean up the mess in sg/st
with their own allocated pages that would have the potential to
significantly simply this code.

> > Sort of related to that is that this does driver the copy to user and
> > unpin from bio_integrity_free, which is a low-level routine.  It really
> > should be driven from the highlevel blk-map code that is the I/O
> > submitter, just like the data side.  Shoe-horning uaccess into the
> > low-level block layer plumbing is just going to get us into trouble.
> 
> Okay, I think I see what you're saying. We can make the existing use
> more like the blk-map code for callers using struct request. The
> proposed iouring generic read/write user metadata would need something
> different, but looks reasonable.

The important point is that the unpin and copy back should be driven by
the submitter side, not matter if it is bio or request based.