On Wed, Jan 18, 2023 at 11:03:52PM +0000, Al Viro wrote: > On Mon, Jan 16, 2023 at 11:57:08PM -0800, Christoph Hellwig wrote: > > On Mon, Jan 16, 2023 at 11:08:24PM +0000, David Howells wrote: > > > Define FOLL_SOURCE_BUF and FOLL_DEST_BUF to indicate to get_user_pages*() > > > and iov_iter_get_pages*() how the buffer is intended to be used in an I/O > > > operation. Don't use READ and WRITE as a read I/O writes to memory and > > > vice versa - which causes confusion. > > > > > > The direction is checked against the iterator's data_source. > > > > Why can't we use the existing FOLL_WRITE? > > I'm really not fond of passing FOLL_... stuff into iov_iter > primitives. That space contains things like FOLL_PIN, which makes > no sense whatsoever for non-user-backed iterators; having the > callers pass it in makes them automatically dependent upon the > iov_iter flavour. Actually, looking at that thing... Currently we use it only for FOLL_PCI_P2PDMA. It alters behaviour of get_user_pages_fast(), but... it is completely ignored for ITER_BVEC or ITER_PIPE. So how the hell is it supposed to work? And ITER_BVEC *can* get there. blkdev_direct_IO() can get anything ->write_iter() can get, and io_uring will feed stuff to it. For that matter, ->read_iter() can lead to it as well, so generic_file_splice_read() can end up passing ITER_PIPE to that sucker. Could somebody give a braindump on that thing? It looks like we have pages that should not be DMA'd to/from unless driver takes some precautions and we want to make sure they won't be fed to drivers that don't take such. With checks done in a very odd place...
