Received: by 2002:a05:6a10:1d13:0:0:0:0 with SMTP id pp19csp1592993pxb; Fri, 27 Aug 2021 12:24:48 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwLNqVqlv+BiuoGNZ59C7sIWB0eaGM8AbJwdZa9X4lwIIuww0JHnhBptyjhSkd9axaj831G X-Received: by 2002:a5d:94c6:: with SMTP id y6mr8916015ior.202.1630092288740; Fri, 27 Aug 2021 12:24:48 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1630092288; cv=none; d=google.com; s=arc-20160816; b=n3xoE3YC7yc2izIy0vhJJVydEQP8rZPfwAhk+qIUcMYcfqF8SyWBLWwO7hVo5TWi4T tc3lHXJW83c8idtYoizmb2h5Fr2vSrVtjsxExk13XPWGcHPFy/FaphCdWP4FaYECyb03 lA8Dt9erDpXTf/d3AyhSo6XuZb1W1nighTj/XfjD5y0ZV6Vu2LqSvRQZwqXUYy0MK4K1 QTA0fm1GHSb6GauG4qg+sLsg3D/1fKfwBBQ3gN6Syp0U1kVYwJ2Q6RZCRLURbk5TNmf5 ig4gB7jYYcqfos/iu7BjHR6s8uxGB07tNMhILlTHmQoTXe3Ad0QfgmVx1bMZwwwBR2yq jXmg== 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=3Tvx3RU8IMooKyswU6J+RZg5dR865+tMKIkMuWQk/OM=; b=gZkSUKQ8z3jF+fp9z9pTfxwX0vsAEDStkwosWlrJZsf1peEvy/rBAlICdcl7k02cdp WlifOz8camamjGnIZ2xOY+EASSGFukpkRFRTtoR6Dg+FT4C+YlLVrI23QGassZx9lvDM mYtrn56pe1F8YGWCF76syajNPxyEuIfQmS1U5X+80yPsVM+ndHIYbqJRU7Z4eZtZsxbj icp6NpvFe6V9hWtgGjFoKjGMqyHzc8WlBCpKpHJgiwK3+gD5yuiVR1pJMFAzWCFKjIe2 zv28ZaB0HaeY4Gpq3go1HBiqvbs0t2eqiHlKP1bngmgNaME6W3FQlanBzgG1GA8CajXi N7qg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-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 e101si6289037jai.50.2021.08.27.12.24.37; Fri, 27 Aug 2021 12:24:48 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-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-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230284AbhH0TYo (ORCPT + 99 others); Fri, 27 Aug 2021 15:24:44 -0400 Received: from zeniv-ca.linux.org.uk ([142.44.231.140]:42932 "EHLO zeniv-ca.linux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229437AbhH0TYn (ORCPT ); Fri, 27 Aug 2021 15:24:43 -0400 Received: from viro by zeniv-ca.linux.org.uk with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1mJhS9-00GZi6-Qq; Fri, 27 Aug 2021 19:23:49 +0000 Date: Fri, 27 Aug 2021 19:23:49 +0000 From: Al Viro To: Linus Torvalds Cc: Andreas Gruenbacher , Christoph Hellwig , "Darrick J. Wong" , Jan Kara , Matthew Wilcox , cluster-devel , linux-fsdevel , Linux Kernel Mailing List , ocfs2-devel@oss.oracle.com Subject: Re: [PATCH v7 05/19] iov_iter: Introduce fault_in_iov_iter_writeable Message-ID: References: <20210827164926.1726765-1-agruenba@redhat.com> <20210827164926.1726765-6-agruenba@redhat.com> 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-kernel@vger.kernel.org On Fri, Aug 27, 2021 at 12:05:32PM -0700, Linus Torvalds wrote: > But see above. People *need* that ternary result, and "bytes/pages > uncopied" is not only the traditional one we use elsewhere in similar > situations, it's the one that has the easiest error tests for existing > users (because zero remains "everything worked"). Could you show the cases where "partial copy, so it's OK" behaviour would break anything? For that you would need the case where partial fault-in is currently rejected by the check checks downstream from there (for failing copy-in/copy-out) would be either missing or would not be handled correctly in case of partial fault-in or would slow a fast path down. I don't see any such cases and I would be very surprised if such existed. If you see any, please describe them - I could be wrong. And I would like to take a good look at any such case and see how well does it handle possible short copy after full fault-in.