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 79DABC4338F for ; Sat, 24 Jul 2021 23:46:12 +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 EFF3260041 for ; Sat, 24 Jul 2021 23:46:11 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org EFF3260041 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=zeniv.linux.org.uk 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 16ONgOrE031210; Sat, 24 Jul 2021 23:46:11 GMT Received: from userp3020.oracle.com (userp3020.oracle.com [156.151.31.79]) by mx0b-00069f02.pphosted.com with ESMTP id 3a09n30vj7-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sat, 24 Jul 2021 23:46:10 +0000 Received: from pps.filterd (userp3020.oracle.com [127.0.0.1]) by userp3020.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 16ONeePO155788; Sat, 24 Jul 2021 23:46:10 GMT Received: from oss.oracle.com (oss-old-reserved.oracle.com [137.254.22.2]) by userp3020.oracle.com with ESMTP id 3a0vmqgepe-1 (version=TLSv1 cipher=AES256-SHA bits=256 verify=NO); Sat, 24 Jul 2021 23:46:09 +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 1m7RFG-0004Zg-LA; Sat, 24 Jul 2021 16:39:50 -0700 Received: from userp3030.oracle.com ([156.151.31.80]) by oss.oracle.com with esmtp (Exim 4.63) (envelope-from ) id 1m7RFC-0004ZG-IJ for ocfs2-devel@oss.oracle.com; Sat, 24 Jul 2021 16:39:46 -0700 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 16ONUlr8054012 for ; Sat, 24 Jul 2021 23:39:46 GMT Received: from mx0a-00069f01.pphosted.com (mx0a-00069f01.pphosted.com [205.220.165.26]) by userp3030.oracle.com with ESMTP id 3a07ysxyct-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Sat, 24 Jul 2021 23:39:45 +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 16ONbGfq028660 for ; Sat, 24 Jul 2021 23:39:43 GMT Received: from zeniv-ca.linux.org.uk (zeniv-ca.linux.org.uk [142.44.231.140]) by mx0b-00069f01.pphosted.com with ESMTP id 3a0921621m-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Sat, 24 Jul 2021 23:39:43 +0000 Received: from viro by zeniv-ca.linux.org.uk with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1m7REv-003hHv-87; Sat, 24 Jul 2021 23:39:29 +0000 Date: Sat, 24 Jul 2021 23:39:29 +0000 From: Al Viro To: Andreas Gruenbacher Message-ID: References: <20210724193449.361667-1-agruenba@redhat.com> <20210724193449.361667-2-agruenba@redhat.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-Source-IP: 142.44.231.140 X-ServerName: zeniv-ca.linux.org.uk X-Proofpoint-SPF-Result: None 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=693 clxscore=239 malwarescore=0 lowpriorityscore=0 impostorscore=0 mlxscore=0 spamscore=0 priorityscore=190 bulkscore=0 suspectscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2104190000 definitions=main-2107240143 domainage_hfrom=9123 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 suspectscore=0 bulkscore=0 phishscore=0 malwarescore=0 spamscore=0 mlxlogscore=830 mlxscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2104190000 definitions=main-2107240142 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 mlxscore=0 phishscore=0 suspectscore=0 adultscore=0 malwarescore=0 spamscore=0 mlxlogscore=999 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2104190000 definitions=main-2107240143 X-Proofpoint-GUID: -A4naO81rq_tRoYZIpmdkQrXNSLScPjU X-Proofpoint-ORIG-GUID: -A4naO81rq_tRoYZIpmdkQrXNSLScPjU On Sun, Jul 25, 2021 at 12:06:41AM +0200, Andreas Gruenbacher wrote: > On Sat, Jul 24, 2021 at 11:57 PM Al Viro wrote: > > On Sat, Jul 24, 2021 at 11:38:20PM +0200, Andreas Gruenbacher wrote: > > > > > 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. > > > > What I'm saying is that in situation when you have cacheline-sized > > poisoned areas, there's no way to get an accurate count of readable > > area other than try and copy it out. > > > > What's more, "something" is essentially useless information - the > > pages might get unmapped right as your function returns; the caller > > still needs to deal with partial copies. And that's a slow path > > by definition, so informing them of a partial fault-in is not > > going to be useful. > > > > As far as callers are concerned, it's "nothing suitable in the > > beginning of the area" vs. "something might be accessible". > > Yes, and the third case would be "something might be accessible, but > not all of it". There probably are callers that give up when they > don't have it all. Who cares? Again, 1) those callers *still* have to cope with copyin/copyout failures halfway through. Fully successful fault-in does not guarantee anything whatsoever. IOW, you won't get rid of any complexity that way. 2) earlier bailout in rare error case is not worth bothering with. If you'd been given an iov_iter spanning an unmapped/unreadable/unwritable area of user memory, it's either a fucking rare race with truncate() of an mmapped file or a pilot error. Neither case is worth optimizing for. The difference between partially accessible and completely accessible at the fault-in time is useless for callers. Really. _______________________________________________ Ocfs2-devel mailing list Ocfs2-devel@oss.oracle.com https://oss.oracle.com/mailman/listinfo/ocfs2-devel