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.
