Received: by 2002:a05:6a10:206:0:0:0:0 with SMTP id 6csp4816394pxj; Tue, 22 Jun 2021 08:36:56 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzp+O1nxfPSQgm4QON+LEg5VoNN7tzDyHbTnKesLYt2DI1DGSrNZcThnZWpAnMuyHT1iupV X-Received: by 2002:a92:874a:: with SMTP id d10mr1575468ilm.145.1624376216839; Tue, 22 Jun 2021 08:36:56 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1624376216; cv=none; d=google.com; s=arc-20160816; b=zXd0XUtdl41OSEO/1FT6WPDEVCKl+fjZ2OU+4oXSrFw+kgKZSyGzI2oxWbiOU3dqmH 3U4vm0NyvLTtc/1mALldUUULul9kI3mCaqd7C+MS6Gip14NmHkFXZ+tKA7/UBBP88HGM jPILhGnerhxQBAw86n034LBSeJguhoDYqIb3Elj47XU5O1ER5rl4sJrd780gEsv8USaw wBZv80+AYhyUCXg8vb9vveVDHAPc2l7OiLa40CM6LDTuyQ8OG8bL5uACFE3v9SSOUTR+ G6U4f+aeiYZ3qboHG1HVh7621fQQJyWHGZ+U0F1pKnTXDnFVIEqkM8FK7UXLdJypP4/2 C4sg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date; bh=DqcsoygtD5SFhh4NaN1uUtvcLSVgBIzx/4s+jxQb1cQ=; b=vuGeqBvV9cXn6t0uXKdJm9yCfr22OFwNJL4zqbNepKuuDSTh7teFjFM37at0q3MTnT GkiDtlDB8+zphxcdr+wrLIQN4oR1G0daoHgFU63lM9MQyPzg7Cz2H+cxpvIPEZ+U5fDb fUImPl7YfkYO0b/ZkkE5g01zK9sWEeUCbVpR93bXhpccTH0qmV4t6IBgMUSdtNymj6D4 Pu7vWpBMWxEWwLMNtUsmpuCgMmdEPqrI89zNVU8AZJeqkvpSTnnoZgZG+IyZ3F6F63IB qHhr2UZTVP/kFOKqDApZQkneaU9hsGXyUe77fha8pNZqgLN66q7p3TrGY+0zYVkA55B5 0dMg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-ext4-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id o12si22883417jat.53.2021.06.22.08.36.43; Tue, 22 Jun 2021 08:36:56 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-ext4-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232051AbhFVPix (ORCPT + 99 others); Tue, 22 Jun 2021 11:38:53 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33252 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231964AbhFVPiw (ORCPT ); Tue, 22 Jun 2021 11:38:52 -0400 Received: from zeniv-ca.linux.org.uk (zeniv-ca.linux.org.uk [IPv6:2607:5300:60:148a::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id BE34DC061574; Tue, 22 Jun 2021 08:36:31 -0700 (PDT) Received: from viro by zeniv-ca.linux.org.uk with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1lviRq-00BENn-NA; Tue, 22 Jun 2021 15:36:22 +0000 Date: Tue, 22 Jun 2021 15:36:22 +0000 From: Al Viro To: David Howells Cc: torvalds@linux-foundation.org, Ted Ts'o , Dave Hansen , Andrew Morton , willy@infradead.org, linux-mm@kvack.org, linux-ext4@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: Do we need to unrevert "fs: do not prefault sys_write() user buffer pages"? Message-ID: References: <3221175.1624375240@warthog.procyon.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: Al Viro Precedence: bulk List-ID: X-Mailing-List: linux-ext4@vger.kernel.org On Tue, Jun 22, 2021 at 03:27:43PM +0000, Al Viro wrote: > On Tue, Jun 22, 2021 at 04:20:40PM +0100, David Howells wrote: > > > and wondering if the iov_iter_fault_in_readable() is actually effective. Yes, > > it can make sure that the page we're intending to modify is dragged into the > > pagecache and marked uptodate so that it can be read from, but is it possible > > for the page to then get reclaimed before we get to > > iov_iter_copy_from_user_atomic()? a_ops->write_begin() could potentially take > > a long time, say if it has to go and get a lock/lease from a server. > > Yes, it is. So what? We'll just retry. You *can't* take faults while holding > some pages locked; not without shitloads of deadlocks. Note that the revert you propose is going to do fault-in anyway; we really can't avoid it. The only thing it does is optimistically trying without that the first time around, which is going to be an overall loss exactly in "slow write_begin" case. If source pages are absent, you'll get copyin fail; iov_iter_copy_from_user_atomic() (or its replacement) is disabling pagefaults itself.