On Thu, Jan 19, 2023 at 12:15:44AM +0000, Al Viro wrote: > 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... PS: Documentation/driver-api/pci/p2pdma.rst seems to imply that those pages should not be possible to mmap, so either that needs to be updated, or... how the hell could we run into those in g-u-p, anyway? Really confused...
