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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20230127123812.qj2v5mtjllutawcq@quack3>
Date:   Fri, 27 Jan 2023 13:38:12 +0100
From:   Jan Kara <jack@...e.cz>
To:     Al Viro <viro@...iv.linux.org.uk>
Cc:     David Howells <dhowells@...hat.com>,
        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 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@...e.com>
SUSE Labs, CR