On 8/31/22 02:43, Jan Kara wrote: >> OK, thanks, that looks viable. So, that approach assumes that the >> remaining two cases in __iov_iter_get_pages_alloc() will never end up >> being released via bio_release_pages(): >> >> iov_iter_is_pipe(i) >> iov_iter_is_xarray(i) >> >> I'm actually a little worried about ITER_XARRAY, which is a recent addition. >> It seems to be used in ways that are similar to ITER_BVEC, and cephfs is >> using it. It's probably OK for now, for this series, which doesn't yet >> convert cephfs. > > So after looking into that a bit more, I think a clean approach would be to > provide iov_iter_pin_pages2() and iov_iter_pages_alloc2(), under the hood > in __iov_iter_get_pages_alloc() make sure we use pin_user_page() instead of > get_page() in all the cases (using this in pipe_get_pages() and > iter_xarray_get_pages() is easy) and then make all bio handling use the > pinning variants for iters. I think at least iov_iter_is_pipe() case needs > to be handled as well because as I wrote above, pipe pages can enter direct > IO code e.g. for splice(2). > OK, yes. > Also I think that all iov_iter_get_pages2() (or the _alloc2 variant) users > actually do want the "pin page" semantics in the end (they are accessing > page contents) so eventually we should convert them all to > iov_iter_pin_pages2() and remove iov_iter_get_pages2() altogether. But this > will take some more conversion work with networking etc. so I'd start with > converting bios only. > > Honza I'll give this approach a spin, thanks very much for the guidance! thanks, -- John Hubbard NVIDIA
