From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-7.2 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 9368DC432BE for ; Sat, 24 Jul 2021 21:38:38 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 71E6760E90 for ; Sat, 24 Jul 2021 21:38:38 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229938AbhGXU6E (ORCPT ); Sat, 24 Jul 2021 16:58:04 -0400 Received: from us-smtp-delivery-124.mimecast.com ([170.10.133.124]:55720 "EHLO us-smtp-delivery-124.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229549AbhGXU6D (ORCPT ); Sat, 24 Jul 2021 16:58:03 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1627162714; h=from:from:reply-to:subject:subject: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=OQ9nYZF7TCv1Im5A1JNzguL1rttUs8MvyEizhk+cJ88=; b=A0eZC9i93zZZTNeGY6Gh7nBtkoWuP+u+qiADG75sylFkWP5trLL8VcjNjWICFTcNoFEevG VxddHrS/nsmyvhsKMBiHgut+oFOWU8E31qj0ArviF9hMItYnUc6nKYEmvvtRe2tcgNLbEv clfWWsR7yLRJ33bVTjnsllUxynATHAY= Received: from mail-wr1-f69.google.com (mail-wr1-f69.google.com [209.85.221.69]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-222-RloOE1wUNLOsPUI_d0EfsQ-1; Sat, 24 Jul 2021 17:38:33 -0400 X-MC-Unique: RloOE1wUNLOsPUI_d0EfsQ-1 Received: by mail-wr1-f69.google.com with SMTP id s8-20020a5d42480000b02901404c442853so2547065wrr.12 for ; Sat, 24 Jul 2021 14:38:32 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=OQ9nYZF7TCv1Im5A1JNzguL1rttUs8MvyEizhk+cJ88=; b=sV7TUZgP/Hy1+hXpaTDIlMstjJNMV6XrX/nKX+CjlAyPCCWJ3aLe0/YpoND71zs6x3 sNSWegBx6UcUFaEwpiGK+Ta6uhSqaUL//N2IqjnkvynQQqO71DfnucBS9wKO+hyQxOa6 AcxpTTKpWlqR4Wt5S3BROHVD1OKBm+pDX4IyAG70TzrkPouy7OYftWrNadSJ6E7U1ZEU JzrHq2Dj2dXg2xoCEVVZJEr903JwWjKp3xzyYZEolIhaRF/+GEt1o9ZuA3yocF6taew/ mtci8cw2QslHToQf+8erD4PETHHjXceXTInAF3ekTcc+rCJ1P14UdFIISD+/NofhLYxc tMcg== X-Gm-Message-State: AOAM531ZLanPbc7MFhoRkeTRxCtnDqOPZz5JMym5Y5p3AQd45tuVlfZW 16lmJhjtjaxKg9QXc28wy4C19E2vXBmPS/5RI60qY4FCIcuk3qqn8MJk0VkwOYe1Zpoq3MwHoLp 1W90MzUy4D0A+ejIG2ikUUVQ50cCmSUibShjRxgzo X-Received: by 2002:adf:f6ca:: with SMTP id y10mr11408639wrp.211.1627162711891; Sat, 24 Jul 2021 14:38:31 -0700 (PDT) X-Google-Smtp-Source: ABdhPJx1Kv/M6qskCAa2iYidDcO94F9rO3w70hsI/xsveCv4ij53/4AEZQooofItTEg7clN8/LfjbNCETI0gEwwmduY= X-Received: by 2002:adf:f6ca:: with SMTP id y10mr11408629wrp.211.1627162711767; Sat, 24 Jul 2021 14:38:31 -0700 (PDT) MIME-Version: 1.0 References: <20210724193449.361667-1-agruenba@redhat.com> <20210724193449.361667-2-agruenba@redhat.com> In-Reply-To: From: Andreas Gruenbacher Date: Sat, 24 Jul 2021 23:38:20 +0200 Message-ID: Subject: Re: [PATCH v4 1/8] iov_iter: Introduce iov_iter_fault_in_writeable helper To: Al Viro Cc: Linus Torvalds , Christoph Hellwig , "Darrick J. Wong" , Jan Kara , Matthew Wilcox , cluster-devel , linux-fsdevel , Linux Kernel Mailing List , ocfs2-devel@oss.oracle.com Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, Jul 24, 2021 at 10:24 PM Al Viro wrote: > On Sat, Jul 24, 2021 at 12:52:34PM -0700, Linus Torvalds wrote: > > ... > > > + if (fault_in_user_pages(start, len, true) != len) > > > + return -EFAULT; > > > > Looking at this once more, I think this is likely wrong. > > > > Why? > > > > Because any user can/should only care about at least *part* of the > > area being writable. > > > > Imagine that you're doing a large read. If the *first* page is > > writable, you should still return the partial read, not -EFAULT. > > Agreed. > > > So I think the code needs to return 0 if _any_ fault was successful. > > s/any/the first/... > > The same goes for fault-in for read, of course; I've a half-baked conversion > to such semantics (-EFAULT vs. 0; precise length is unreliable anyway, > especially if you have sub-page failure areas), need to finish and post > it... Hmm, how could we have sub-page failure areas when this is about if and how pages are mapped? If we return the number of bytes that are accessible, then users will know if they got nothing, something, or everything, and they can act accordingly. Thanks, Andreas