Re: [PATCH v11 2/8] iov_iter: Add a function to extract a page list from an iterator

[Jan Kara]

On Fri 27-01-23 00:52:38, Al Viro wrote:
> On Thu, Jan 26, 2023 at 11:56:50PM +0000, David Howells wrote:
> > Al says that pinning a page (ie. FOLL_PIN) could cause a deadlock if a page is
> > vmspliced into a pipe with the pipe holding a pin on it because pinned pages
> > are removed from all page tables.  Is this actually the case?  I can't see
> > offhand where in mm/gup.c it does this.
> 
> It doesn't; sorry, really confused memories of what's going on, took a while
> to sort them out (FWIW, writeback is where we unmap and check if page is
> pinned, while pin_user_pages running into an unmapped page will end up
> with handle_mm_fault() (->fault(), actually) try to get the sucker locked
> and block on that until the writeback is over).
> 
> Said that, I still think that pinned pages (arbitrary pagecache ones,
> at that) ending up in a pipe is a seriously bad idea.  It's trivial to
> arrange for them to stay that way indefinitely - no priveleges needed,
> very few limits, etc.

I tend to agree but is there a big difference compared to normal page
references? There's no difference for memory usage, pages still can be
truncated from the file and disk space reclaimed (this is where DAX has
problems...) so standard file operations won't notice. The only difference
is that they could stay permanently dirty (we don't know whether the pin
owner copies data to or from the page) so it could cause trouble with dirty
throttling - and it is really only the throttling itself - page reclaim
will have the same troubles with both pins and ordinary page references...
Am I missing something?

								Honza
-- 
Jan Kara <jack@xxxxxxxx>
SUSE Labs, CR