[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Y9MgVsrMdgGsxNHC@ZenIV>
Date: Fri, 27 Jan 2023 00:52:38 +0000
From: Al Viro <viro@...iv.linux.org.uk>
To: David Howells <dhowells@...hat.com>
Cc: David Hildenbrand <david@...hat.com>,
Christoph Hellwig <hch@...radead.org>,
Matthew Wilcox <willy@...radead.org>,
Jens Axboe <axboe@...nel.dk>, Jan Kara <jack@...e.cz>,
Jeff Layton <jlayton@...nel.org>,
Jason Gunthorpe <jgg@...dia.com>,
Logan Gunthorpe <logang@...tatee.com>,
linux-fsdevel@...r.kernel.org, linux-block@...r.kernel.org,
linux-kernel@...r.kernel.org, linux-mm@...ck.org,
Christoph Hellwig <hch@....de>,
John Hubbard <jhubbard@...dia.com>
Subject: Re: [PATCH v11 2/8] iov_iter: Add a function to extract a page list
from an iterator
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.
Powered by blists - more mailing lists