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 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=-3.8 required=3.0 tests=BAYES_00, 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 DF802C4338F for ; Sat, 24 Jul 2021 21:41:57 +0000 (UTC) Received: from mx0b-00069f02.pphosted.com (mx0b-00069f02.pphosted.com [205.220.177.32]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 6AD3260E09 for ; Sat, 24 Jul 2021 21:41:57 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 6AD3260E09 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=oss.oracle.com Received: from pps.filterd (m0246631.ppops.net [127.0.0.1]) by mx0b-00069f02.pphosted.com (8.16.0.43/8.16.0.43) with SMTP id 16OLfb4e032514; Sat, 24 Jul 2021 21:41:56 GMT Received: from userp3030.oracle.com (userp3030.oracle.com [156.151.31.80]) by mx0b-00069f02.pphosted.com with ESMTP id 3a09n30tsm-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sat, 24 Jul 2021 21:41:56 +0000 Received: from pps.filterd (userp3030.oracle.com [127.0.0.1]) by userp3030.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 16OLeijl067816; Sat, 24 Jul 2021 21:41:55 GMT Received: from oss.oracle.com (oss-old-reserved.oracle.com [137.254.22.2]) by userp3030.oracle.com with ESMTP id 3a07ysth1p-1 (version=TLSv1 cipher=AES256-SHA bits=256 verify=NO); Sat, 24 Jul 2021 21:41:55 +0000 Received: from localhost ([127.0.0.1] helo=lb-oss.oracle.com) by oss.oracle.com with esmtp (Exim 4.63) (envelope-from ) id 1m7PM5-0006z0-8x; Sat, 24 Jul 2021 14:38:45 -0700 Received: from aserp3030.oracle.com ([141.146.126.71]) by oss.oracle.com with esmtp (Exim 4.63) (envelope-from ) id 1m7PLy-0006yU-JK for ocfs2-devel@oss.oracle.com; Sat, 24 Jul 2021 14:38:38 -0700 Received: from pps.filterd (aserp3030.oracle.com [127.0.0.1]) by aserp3030.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 16OLZVYP155110 for ; Sat, 24 Jul 2021 21:38:38 GMT Received: from mx0a-00069f01.pphosted.com (mx0a-00069f01.pphosted.com [205.220.165.26]) by aserp3030.oracle.com with ESMTP id 3a08wc3tg3-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Sat, 24 Jul 2021 21:38:37 +0000 Received: from pps.filterd (m0246573.ppops.net [127.0.0.1]) by mx0b-00069f01.pphosted.com (8.16.0.43/8.16.0.43) with SMTP id 16OLXr8P003541 for ; Sat, 24 Jul 2021 21:38:36 GMT Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [216.205.24.124]) by mx0b-00069f01.pphosted.com with ESMTP id 3a09215kmj-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Sat, 24 Jul 2021 21:38:35 +0000 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-217-YTQgJLuCN9u3XUuQoSNiZg-1; Sat, 24 Jul 2021 17:38:32 -0400 X-MC-Unique: YTQgJLuCN9u3XUuQoSNiZg-1 Received: by mail-wr1-f69.google.com with SMTP id r17-20020adfda510000b02901526f76d738so2593761wrl.0 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=RqMH3ergvrK/HHxIUPOTgY0evN2dam+mdbYs5ePtJGHrGXH+kQ5bk57cHQ053wxpCg gdZpYCoszWMg6Dd9FUm34gz9od8Ia/8aqaTl90gzzmnxwqCjJsE6Y54bgV5dIOH4qtFY 5k4dQuC6RLHU8jkHxqwMZmWcSJYqD6W9jKLaEVBdjDARU5LVgOyokxaZhW6lC1/aG6Bk /tCmSYL3eFrPoevRZew0ZIg3cb4A2CXZ3S5BiTMhWmPmke1BcLvUl3H0f5nrwoQ8+W0Y xfry0xDfuW+/Yb8h4LEWxkRvHZFKLry6Wi2NEtE7GUGcO/IeZ3v6VRSDL+MMxTtmUwBW /eIA== X-Gm-Message-State: AOAM530xU4kxlEpntHl+KEsA843AdR4RL1udPY2dhneZAIJPbUpEYMZv J7IMrq25QGoDNSq1loZNeS3S6e/e2EHK0bX6DZJDwchyW2ytTG16TW9p96zIoDJSDi7vdsRP5qj 0x38e0oZxIspdRqxs0ELo9K8ExNK7VeRquEXgyA== X-Received: by 2002:adf:f6ca:: with SMTP id y10mr11408640wrp.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: To: Al Viro Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=agruenba@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com X-Proofpoint-SPF-Result: pass X-Proofpoint-SPF-Record: v=spf1 ip4:103.23.64.2 ip4:103.23.65.2 ip4:103.23.66.26 ip4:103.23.67.26 ip4:107.21.15.141 ip4:108.177.8.0/21 ip4:128.17.0.0/20 ip4:128.17.128.0/20 ip4:128.17.192.0/20 ip4:128.17.64.0/20 ip4:128.245.0.0/20 ip4:128.245.64.0/20 ip4:13.110.208.0/21 ip4:13.111.0.0/16 ip4:136.147.128.0/20 ip4:136.147.176.0/20 ip4:148.105.8.0/21 ip4:148.139.0.2 include:spf1.redhat.com -all X-Proofpoint-SPF-VenPass: Allowed X-Source-IP: 216.205.24.124 X-ServerName: us-smtp-delivery-124.mimecast.com X-Proofpoint-SPF-Result: pass X-Proofpoint-SPF-Record: v=spf1 ip4:103.23.64.2 ip4:103.23.65.2 ip4:103.23.66.26 ip4:103.23.67.26 ip4:107.21.15.141 ip4:108.177.8.0/21 ip4:128.17.0.0/20 ip4:128.17.128.0/20 ip4:128.17.192.0/20 ip4:128.17.64.0/20 ip4:128.245.0.0/20 ip4:128.245.64.0/20 ip4:13.110.208.0/21 ip4:13.111.0.0/16 ip4:136.147.128.0/20 ip4:136.147.176.0/20 ip4:148.105.8.0/21 ip4:148.139.0.2 include:spf1.redhat.com -all X-Proofpoint-Virus-Version: vendor=nai engine=6200 definitions=10055 signatures=668682 X-Proofpoint-Spam-Reason: safe X-Spam: OrgSafeList X-SpamRule: orgsafelist X-Proofpoint-Virus-Version: vendor=nai engine=6200 definitions=10055 signatures=668682 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 malwarescore=0 adultscore=0 bulkscore=0 phishscore=0 suspectscore=0 mlxscore=0 mlxlogscore=991 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2104190000 definitions=main-2107240130 Cc: cluster-devel , Jan Kara , Linux Kernel Mailing List , Christoph Hellwig , linux-fsdevel , Linus Torvalds , ocfs2-devel@oss.oracle.com Subject: Re: [Ocfs2-devel] [PATCH v4 1/8] iov_iter: Introduce iov_iter_fault_in_writeable helper X-BeenThere: ocfs2-devel@oss.oracle.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ocfs2-devel-bounces@oss.oracle.com Errors-To: ocfs2-devel-bounces@oss.oracle.com X-Proofpoint-Virus-Version: vendor=nai engine=6200 definitions=10055 signatures=668682 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 bulkscore=0 phishscore=0 malwarescore=0 spamscore=0 mlxlogscore=999 mlxscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2104190000 definitions=main-2107240131 X-Proofpoint-GUID: b4XM8nZw6-xe3eiFtcsU95_Zree2qOqn X-Proofpoint-ORIG-GUID: b4XM8nZw6-xe3eiFtcsU95_Zree2qOqn 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 _______________________________________________ Ocfs2-devel mailing list Ocfs2-devel@oss.oracle.com https://oss.oracle.com/mailman/listinfo/ocfs2-devel From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andreas Gruenbacher Date: Sat, 24 Jul 2021 23:38:20 +0200 Subject: [Cluster-devel] [PATCH v4 1/8] iov_iter: Introduce iov_iter_fault_in_writeable helper In-Reply-To: References: <20210724193449.361667-1-agruenba@redhat.com> <20210724193449.361667-2-agruenba@redhat.com> Message-ID: List-Id: To: cluster-devel.redhat.com MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit 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