On 5/6/2024 11:35 AM, Christoph Hellwig wrote: > Can we take a step back first? > > Current the blk-map user buffer handling decided to either pin > the memory and use that directly or use the normal user copy helpers > through copy_page_to_iter/copy_page_from_iter. > > Why do we even pin the memory here to then do an in-kernel copy instead > of doing the copy_from/to_user which is going to be a lot more efficient? Many good reasons for that. Keeping the user meta memory pinned allows to update it nicely during completion. Otherwise, it required using task-work, lots of bookkeeping in driver (nvme), and all that was pretty convoluted. Please see this series (you have reviewed in past): https://lore.kernel.org/linux-block/20231130215309.2923568-1-kbusch@xxxxxxxx/#r Nvme and io_uring (Patch 2, 3, 4) get nice wins because of keeping the user memory pinned even for bounce-buffer case. > 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. > Not sure I follow, but citing this nvme patch again: https://lore.kernel.org/linux-block/20231130215309.2923568-3-kbusch@xxxxxxxx/ Driver does not need to know whether meta was handled by pinning or by using bounce buffer. Everything is centrally handled in block/bio-integrity.c.
