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=-5.8 required=3.0 tests=BAYES_00,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 62388C4338F for ; Sat, 24 Jul 2021 20:37:40 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 47B0660E96 for ; Sat, 24 Jul 2021 20:37:40 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229625AbhGXT5F (ORCPT ); Sat, 24 Jul 2021 15:57:05 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39898 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229508AbhGXT47 (ORCPT ); Sat, 24 Jul 2021 15:56:59 -0400 Received: from mail-lj1-x22d.google.com (mail-lj1-x22d.google.com [IPv6:2a00:1450:4864:20::22d]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 0E6DFC061757 for ; Sat, 24 Jul 2021 13:37:29 -0700 (PDT) Received: by mail-lj1-x22d.google.com with SMTP id n6so6186482ljp.9 for ; Sat, 24 Jul 2021 13:37:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ho2aOvJzVUGxbigA5Ok8jwjbjidvHRLuevL3w0ehES8=; b=RYJdn54XZvqgDpdCoHMx7X/1qdNndwkSiwPLlTPxcMWweYY3UpjJeM3vyKj+NX7+9Q cWCj7Nl9Y+araWN9VJGCF1HNiqElOH2DLKWtSDySUgro0NqFzvf69OLHIXVIRFhQlf1q ehxcrzIzzq3rOn8v+Y3XavxPhUhKvOx9U+xKs= 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=ho2aOvJzVUGxbigA5Ok8jwjbjidvHRLuevL3w0ehES8=; b=jHXioLRt4Vyks8TOP60ruuXwV5Pp2PcastlQdY30H19suW83HJVvUPFFSiAaLSLCo+ QaSw06TaCZKjp4ZvlQ1WMNj9WNba/vp7FNkiRI0q0hGy6t8ttpwG3POgFitk9WVlL02k xj6/hFDEs4Ge0qzwYPX0Ps77Y6fFHzyNmVyyZhGNipZiGZopVn5MwfA3kJSOIHJsPmK3 RXw0j3nhI8o6I8FLRNLjyNS+CBCXw7z9nFhQ28tN7eji5YAPQk9QzFj5e7J53ESnTeRu kPIPJGAQAyvc5n07cEvmEzDstDIN0e6ehr9VN+EwZCkGmF3bmWj+vZG/zCHI0it1ldr7 PF6A== X-Gm-Message-State: AOAM530qtuH3TSKcr8nljv9IhAC+mgK1xdRIXjedyGclpWdQTxe2dSkj PlWWc8wknwAMUIdC/cAuHzm76SCn3Fw9nlRd X-Google-Smtp-Source: ABdhPJzMZssFMKLSxiScdLu8RaP3AebGvQgSr63hoMu303YRxov5pvyjTaouNU7w+arLfoMFNoEO5g== X-Received: by 2002:a05:651c:130f:: with SMTP id u15mr7396605lja.485.1627159047672; Sat, 24 Jul 2021 13:37:27 -0700 (PDT) Received: from mail-lf1-f47.google.com (mail-lf1-f47.google.com. [209.85.167.47]) by smtp.gmail.com with ESMTPSA id q14sm2574020lfe.106.2021.07.24.13.37.26 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 24 Jul 2021 13:37:26 -0700 (PDT) Received: by mail-lf1-f47.google.com with SMTP id h2so8173599lfu.4 for ; Sat, 24 Jul 2021 13:37:26 -0700 (PDT) X-Received: by 2002:ac2:44ad:: with SMTP id c13mr7135571lfm.377.1627159045780; Sat, 24 Jul 2021 13:37:25 -0700 (PDT) MIME-Version: 1.0 References: <20210724193449.361667-1-agruenba@redhat.com> <20210724193449.361667-2-agruenba@redhat.com> In-Reply-To: From: Linus Torvalds Date: Sat, 24 Jul 2021 13:37:09 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v4 1/8] iov_iter: Introduce iov_iter_fault_in_writeable helper To: Al Viro 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 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 1:26 PM Al Viro wrote: > > On Sat, Jul 24, 2021 at 12:52:34PM -0700, Linus Torvalds wrote: > > > So I think the code needs to return 0 if _any_ fault was successful. > > s/any/the first/... Yes, but as long as we do them in order, and stop when it fails, "any" and "first" end up being the same thing ;) > The same goes for fault-in for read Yeah. That said, a partial write() (ie "read from user space") might be something that a filesystem is not willing to touch for other reasons, so I think returning -EFAULT in that case is, I think, slightly more reasonable. Things like "I have to prepare buffers to be filled" etc. The partial read() case is at least something that a filesystem should be able to handle fairly easily. And I don't think returning -EFAULT early is necessarily wrong - we obviously do it anyway if you give really invalid addresses. But we have generally strived to allow partial IO for missing pages, because people sometimes play games with unmapping things dynamically or using mprotect() to catch modifications (ie doing things like catch SIGSEGV/SIGBUS, and remap it). But those kinds of uses tend to have to catch -EFAULT anyway, so I guess it's not a big deal either way. Linus 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 96A71C4320A for ; Sat, 24 Jul 2021 20:37:40 +0000 (UTC) Received: from mx0a-00069f02.pphosted.com (mx0a-00069f02.pphosted.com [205.220.165.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 3ECF360725 for ; Sat, 24 Jul 2021 20:37:40 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 3ECF360725 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=linux-foundation.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=oss.oracle.com Received: from pps.filterd (m0246617.ppops.net [127.0.0.1]) by mx0b-00069f02.pphosted.com (8.16.0.43/8.16.0.43) with SMTP id 16OKavkA006435; Sat, 24 Jul 2021 20:37:39 GMT Received: from userp3030.oracle.com (userp3030.oracle.com [156.151.31.80]) by mx0b-00069f02.pphosted.com with ESMTP id 3a0bdrrs04-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sat, 24 Jul 2021 20:37:39 +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 16OKYivK149749; Sat, 24 Jul 2021 20:37:38 GMT Received: from oss.oracle.com (oss-old-reserved.oracle.com [137.254.22.2]) by userp3030.oracle.com with ESMTP id 3a07ysre51-1 (version=TLSv1 cipher=AES256-SHA bits=256 verify=NO); Sat, 24 Jul 2021 20:37:38 +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 1m7OOv-0004Co-7p; Sat, 24 Jul 2021 13:37:37 -0700 Received: from aserp3030.oracle.com ([141.146.126.71]) by oss.oracle.com with esmtp (Exim 4.63) (envelope-from ) id 1m7OOp-0004CM-Ng for ocfs2-devel@oss.oracle.com; Sat, 24 Jul 2021 13:37:31 -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 16OKZWqP056247 for ; Sat, 24 Jul 2021 20:37:31 GMT Received: from mx0a-00069f01.pphosted.com (mx0a-00069f01.pphosted.com [205.220.165.26]) by aserp3030.oracle.com with ESMTP id 3a08wc1nfs-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Sat, 24 Jul 2021 20:37:31 +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 16OKb9sT029965 for ; Sat, 24 Jul 2021 20:37:30 GMT Received: from mail-lj1-f181.google.com (mail-lj1-f181.google.com [209.85.208.181]) by mx0b-00069f01.pphosted.com with ESMTP id 3a09215c6h-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=OK) for ; Sat, 24 Jul 2021 20:37:30 +0000 Received: by mail-lj1-f181.google.com with SMTP id x7so6184829ljn.10 for ; Sat, 24 Jul 2021 13:37:29 -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=ho2aOvJzVUGxbigA5Ok8jwjbjidvHRLuevL3w0ehES8=; b=HdpJWfqZ/C+wPP3O5kkS1QeSQSMy3WKIXynxQHR63hyfL+xnVPpbNwg34xxVkXdsyP 5Gpy1TcBuXw0rTZL/dju5YtdsTtmSJGHfUScbbTtDgDlTt6r1P1OG00hDBew+QAKsU8f +ObfPw6CSI/1bw/bwZM/624tJitGg8UXw6ZQmO37oaJsvl+DHA8uyGCA3SHCsd2HH+N1 fR7HJX+zsoxPYPZgIEzLI880ezXtF+lWZXWre156Dr1iEgVdbGRbKZM2FWBT61DagyM1 arGl22bkf+CCdhpaTHriNhlejITrYqWGZo66G/5ThMLFR62M/+w1/Wym87u30SQ2k+Hg P+6w== X-Gm-Message-State: AOAM531O+Xl5giAKDkmYCOrapb7rqH7vAqMsawDVyXkXmtnpmXBpI79U /59Y5E3mst7ZJN4fFd2mEWew8G7Z2m583mSp X-Google-Smtp-Source: ABdhPJyZ2euUJbesL7b8aOIOeb0DaaxihaORkB+lCD6SDNw+m3arQTldPFky8rxGe+rvqYqtjMLhyw== X-Received: by 2002:a2e:9b84:: with SMTP id z4mr7236807lji.179.1627159047392; Sat, 24 Jul 2021 13:37:27 -0700 (PDT) Received: from mail-lf1-f54.google.com (mail-lf1-f54.google.com. [209.85.167.54]) by smtp.gmail.com with ESMTPSA id a3sm2580398lfl.134.2021.07.24.13.37.26 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 24 Jul 2021 13:37:26 -0700 (PDT) Received: by mail-lf1-f54.google.com with SMTP id u3so8105628lff.9 for ; Sat, 24 Jul 2021 13:37:26 -0700 (PDT) X-Received: by 2002:ac2:44ad:: with SMTP id c13mr7135571lfm.377.1627159045780; Sat, 24 Jul 2021 13:37:25 -0700 (PDT) MIME-Version: 1.0 References: <20210724193449.361667-1-agruenba@redhat.com> <20210724193449.361667-2-agruenba@redhat.com> In-Reply-To: From: Linus Torvalds Date: Sat, 24 Jul 2021 13:37:09 -0700 X-Gmail-Original-Message-ID: Message-ID: To: Al Viro X-Source-IP: 209.85.208.181 X-ServerName: mail-lj1-f181.google.com X-Proofpoint-SPF-Result: pass X-Proofpoint-SPF-Record: v=spf1 ip4:198.145.29.98/31 ip4:72.55.140.81 include:_spf.google.com include:amazonses.com include:_spf.salesforce.com ~all X-Proofpoint-Virus-Version: vendor=nai engine=6200 definitions=10055 signatures=668682 X-Proofpoint-Spam-Details: rule=tap_notspam policy=tap score=0 phishscore=0 mlxlogscore=751 clxscore=393 malwarescore=0 lowpriorityscore=0 impostorscore=0 mlxscore=0 spamscore=0 priorityscore=269 bulkscore=0 suspectscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2104190000 definitions=main-2107240124 X-Spam: Clean 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=878 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2104190000 definitions=main-2107240124 Cc: cluster-devel , Jan Kara , Andreas Gruenbacher , Linux Kernel Mailing List , Christoph Hellwig , linux-fsdevel , 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-2107240124 X-Proofpoint-GUID: lKJu7TugRAmqOvYhyDCr8uYsi3eOQPsn X-Proofpoint-ORIG-GUID: lKJu7TugRAmqOvYhyDCr8uYsi3eOQPsn On Sat, Jul 24, 2021 at 1:26 PM Al Viro wrote: > > On Sat, Jul 24, 2021 at 12:52:34PM -0700, Linus Torvalds wrote: > > > So I think the code needs to return 0 if _any_ fault was successful. > > s/any/the first/... Yes, but as long as we do them in order, and stop when it fails, "any" and "first" end up being the same thing ;) > The same goes for fault-in for read Yeah. That said, a partial write() (ie "read from user space") might be something that a filesystem is not willing to touch for other reasons, so I think returning -EFAULT in that case is, I think, slightly more reasonable. Things like "I have to prepare buffers to be filled" etc. The partial read() case is at least something that a filesystem should be able to handle fairly easily. And I don't think returning -EFAULT early is necessarily wrong - we obviously do it anyway if you give really invalid addresses. But we have generally strived to allow partial IO for missing pages, because people sometimes play games with unmapping things dynamically or using mprotect() to catch modifications (ie doing things like catch SIGSEGV/SIGBUS, and remap it). But those kinds of uses tend to have to catch -EFAULT anyway, so I guess it's not a big deal either way. Linus _______________________________________________ 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: Linus Torvalds Date: Sat, 24 Jul 2021 13:37:09 -0700 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 1:26 PM Al Viro wrote: > > On Sat, Jul 24, 2021 at 12:52:34PM -0700, Linus Torvalds wrote: > > > So I think the code needs to return 0 if _any_ fault was successful. > > s/any/the first/... Yes, but as long as we do them in order, and stop when it fails, "any" and "first" end up being the same thing ;) > The same goes for fault-in for read Yeah. That said, a partial write() (ie "read from user space") might be something that a filesystem is not willing to touch for other reasons, so I think returning -EFAULT in that case is, I think, slightly more reasonable. Things like "I have to prepare buffers to be filled" etc. The partial read() case is at least something that a filesystem should be able to handle fairly easily. And I don't think returning -EFAULT early is necessarily wrong - we obviously do it anyway if you give really invalid addresses. But we have generally strived to allow partial IO for missing pages, because people sometimes play games with unmapping things dynamically or using mprotect() to catch modifications (ie doing things like catch SIGSEGV/SIGBUS, and remap it). But those kinds of uses tend to have to catch -EFAULT anyway, so I guess it's not a big deal either way. Linus