Received: by 2002:a05:6a10:1d13:0:0:0:0 with SMTP id pp19csp1589820pxb; Fri, 27 Aug 2021 12:20:02 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwMQRXR/utWNtLdwJVIM7x8O71tU0BWhUYO/dzD20pS0tKCcGl7MzsS3o5tII+B2DLG2dvY X-Received: by 2002:a02:ab87:: with SMTP id t7mr9472622jan.127.1630092002381; Fri, 27 Aug 2021 12:20:02 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1630092002; cv=none; d=google.com; s=arc-20160816; b=uhfBNo22QnvxvHCbVLT75x69gwpE53OjloPWgdDvsnEIGNyo4RWMvzKITKaXKwlB4D rm3rEmToCyvRICp9LQE8hkfelvcCROIGcdIjokalFSHJAjrxPAPNrojkZ6W9/lfDSLTK YbvqrDSiyeUbTfrEag4u+Vu+hy4vpJERobYZo1QmtcK2ZPVdXCZyYaAYuqmXiEyNVc7D QR7tMgWV2byrxqgMVtR7Tv4Hte73UWNjexrK6EOa3Ljij4EYgVB/ku3cMc5LzWbyGoVS H8OhofTJHOVSitvW3r2Qiqlawk/eLrmJn3Pu63xeGU9ebP0pswiKSzgEYFekUqBcf6uF mw7A== 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=kFV4cLw1cnoGHgkuIoeRgitjRKjF5aT6ZNIsIp2alpE=; b=HFBx5zY7zRpDGqVTNIhYOyi7ERammYP9RDC6UOQL7FX68P2nd0xS8fwVhIEUoMzsir q41zrXLvzUYUjf0h81Qtq7sV0XptldBeulxmCNuZH0DKdvNR5jCc+HiLy0oRdXHncW/K z+EcBUv8Nc+Aikg2F2HaFSfmKrYm0b7weJ1p0WQI8Zi2CYw7Nt3ylDVyYF3R22QV9rXo Y18DrLPuzLE2Eut6YJqYZkW15aRzTOQMxHKgwY+RK93WUF3g+/kjsmgUL5hnoCG8iIbV NP6hgURFalOfL2/kfsE7sHKuoSeTKm8lT/unkAV8oXlYiOKWm5eEDihrjUr4Aw08+718 fFFQ== 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 g8si6302435ioq.76.2021.08.27.12.19.51; Fri, 27 Aug 2021 12:20:02 -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 S231473AbhH0TTf (ORCPT + 99 others); Fri, 27 Aug 2021 15:19:35 -0400 Received: from zeniv-ca.linux.org.uk ([142.44.231.140]:42758 "EHLO zeniv-ca.linux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231262AbhH0TTT (ORCPT ); Fri, 27 Aug 2021 15:19:19 -0400 Received: from viro by zeniv-ca.linux.org.uk with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1mJhKn-00GZbg-UX; Fri, 27 Aug 2021 19:16:13 +0000 Date: Fri, 27 Aug 2021 19:16:13 +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 04/19] iov_iter: Turn iov_iter_fault_in_readable into fault_in_iov_iter_readable Message-ID: References: <20210827164926.1726765-1-agruenba@redhat.com> <20210827164926.1726765-5-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 11:57:19AM -0700, Linus Torvalds wrote: > On Fri, Aug 27, 2021 at 11:53 AM Al Viro wrote: > > > > I really disagree with these calling conventions. "Number not faulted in" > > is bloody useless > > It's what we already have for copy_to/from_user(), so it's actually > consistent with that. After copy_to/copy_from you've got the data copied and it's not going anywhere. After fault-in you still have to copy, and it still can give you less data than fault-in had succeeded for. So you must handle short copies separately, no matter how much you've got from fault-in. > And it avoids changing all the existing tests where people really > cared only about the "everything ok" case. The thing is, the checks tend to be wrong. We can't rely upon the full fault-in to expect the full copy-in/copy-out, so the checks downstream are impossible to avoid anyway. And fault-in failure is always a slow path, so we are not saving time here. And for the memory poisoining we end up aborting a copy potentially a lot earlier than we should. > Andreas' first patch did that changed version, and was ugly as hell. > > But if you have a version that avoids the ugliness... I'll need to dig my notes out...