Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 0AC1EC54EAA for ; Fri, 27 Jan 2023 12:39:39 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234284AbjA0Mjh (ORCPT ); Fri, 27 Jan 2023 07:39:37 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:49260 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234285AbjA0MjB (ORCPT ); Fri, 27 Jan 2023 07:39:01 -0500 Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.220.29]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 675EE74A63; Fri, 27 Jan 2023 04:38:14 -0800 (PST) Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by smtp-out2.suse.de (Postfix) with ESMTPS id 191481FEC1; Fri, 27 Jan 2023 12:38:13 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1674823093; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=zFTeq0Ir3N0EQQDMB0lGOwLZFNJenO+6frYOzCsuQKs=; b=jCP327G2dfrI2QqS8DkXJJpArCLMvNvuEfU8Ewt1Uhmy0Kb0xGllkzkgC22K2pWQlOmfMD 4kGWg2Rrm7MiaRAoRvF6COqldN+34BS4lxlqdicszAUnAZjf9sKAEKSc704MViQht8nNl9 7mw+T5A3gPoWHWrh48v4ZDRRmM4LJUs= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1674823093; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=zFTeq0Ir3N0EQQDMB0lGOwLZFNJenO+6frYOzCsuQKs=; b=54sm+x/VqYq1b99FVNZ6kbI0fjZp3HiJ+ifLGBybOL1CSDsvofjo0hQHokdR38PbQ6VFNr OCgoKYXa5FSjmMCA== Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by imap2.suse-dmz.suse.de (Postfix) with ESMTPS id 02A961336F; Fri, 27 Jan 2023 12:38:13 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id l3KmALXF02MdBwAAMHmgww (envelope-from ); Fri, 27 Jan 2023 12:38:13 +0000 Received: by quack3.suse.cz (Postfix, from userid 1000) id 77ED2A06B4; Fri, 27 Jan 2023 13:38:12 +0100 (CET) Date: Fri, 27 Jan 2023 13:38:12 +0100 From: Jan Kara To: Al Viro Cc: David Howells , David Hildenbrand , Christoph Hellwig , Matthew Wilcox , Jens Axboe , Jan Kara , Jeff Layton , Jason Gunthorpe , Logan Gunthorpe , linux-fsdevel@vger.kernel.org, linux-block@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, Christoph Hellwig , John Hubbard Subject: Re: [PATCH v11 2/8] iov_iter: Add a function to extract a page list from an iterator Message-ID: <20230127123812.qj2v5mtjllutawcq@quack3> References: <20230126141626.2809643-1-dhowells@redhat.com> <20230126141626.2809643-3-dhowells@redhat.com> <2907150.1674777410@warthog.procyon.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 SUSE Labs, CR