From mboxrd@z Thu Jan 1 00:00:00 1970 From: Catalin Marinas Date: Wed, 20 Oct 2021 17:36:56 +0100 Subject: [Cluster-devel] [PATCH v8 00/17] gfs2: Fix mmap + page fault deadlocks In-Reply-To: References: <20211019134204.3382645-1-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 Tue, Oct 19, 2021 at 05:40:13AM -1000, Linus Torvalds wrote: > On Tue, Oct 19, 2021 at 3:42 AM Andreas Gruenbacher wrote: > > * Will Catalin Marinas's work for supporting arm64 sub-page faults > > be queued behind these patches? We have an overlap in > > fault_in_[pages_]readable fault_in_[pages_]writeable, so one of > > the two patch queues will need some adjustments. > > I think that on the whole they should be developed separately, I don't > think it's going to be a particularly difficult conflict. > > That whole discussion does mean that I suspect that we'll have to > change fault_in_iov_iter_writeable() to do the "every 16 bytes" or > whatever thing, and make it use an actual atomic "add zero" or > whatever rather than walk the page tables. But that's a conceptually > separate discussion from this one, I wouldn't actually want to mix up > the two issues too much. I agree we shouldn't mix the two at the moment. The MTE fix requires some more thinking and it's not 5.16 material yet. The atomic "add zero" trick isn't that simple for MTE since the arm64 atomic or exclusive instructions run with kernel privileges and therefore with the kernel tag checking mode. We could toggle the mode to match user's just for those atomic ops but it will make this probing even more expensive (though normally it's done on the slow path). The quick/backportable fix for MTE is probably to just disable tag checking on user addresses during pagefault_disabled(). As I mentioned in the other thread, a more elaborate fix I think is to change the uaccess routines to update an error code somewhere in a similar way to the arm64 __put_user_error(). But that would require changing lots of callers. -- Catalin From mboxrd@z Thu Jan 1 00:00:00 1970 From: Catalin Marinas Date: Wed, 20 Oct 2021 16:36:56 +0000 Subject: Re: [PATCH v8 00/17] gfs2: Fix mmap + page fault deadlocks Message-Id: List-Id: References: <20211019134204.3382645-1-agruenba@redhat.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Linus Torvalds Cc: Andreas Gruenbacher , Paul Mackerras , Alexander Viro , Christoph Hellwig , "Darrick J. Wong" , Jan Kara , Matthew Wilcox , cluster-devel , linux-fsdevel , Linux Kernel Mailing List , ocfs2-devel@oss.oracle.com, kvm-ppc@vger.kernel.org, linux-btrfs On Tue, Oct 19, 2021 at 05:40:13AM -1000, Linus Torvalds wrote: > On Tue, Oct 19, 2021 at 3:42 AM Andreas Gruenbacher wrote: > > * Will Catalin Marinas's work for supporting arm64 sub-page faults > > be queued behind these patches? We have an overlap in > > fault_in_[pages_]readable fault_in_[pages_]writeable, so one of > > the two patch queues will need some adjustments. > > I think that on the whole they should be developed separately, I don't > think it's going to be a particularly difficult conflict. > > That whole discussion does mean that I suspect that we'll have to > change fault_in_iov_iter_writeable() to do the "every 16 bytes" or > whatever thing, and make it use an actual atomic "add zero" or > whatever rather than walk the page tables. But that's a conceptually > separate discussion from this one, I wouldn't actually want to mix up > the two issues too much. I agree we shouldn't mix the two at the moment. The MTE fix requires some more thinking and it's not 5.16 material yet. The atomic "add zero" trick isn't that simple for MTE since the arm64 atomic or exclusive instructions run with kernel privileges and therefore with the kernel tag checking mode. We could toggle the mode to match user's just for those atomic ops but it will make this probing even more expensive (though normally it's done on the slow path). The quick/backportable fix for MTE is probably to just disable tag checking on user addresses during pagefault_disabled(). As I mentioned in the other thread, a more elaborate fix I think is to change the uaccess routines to update an error code somewhere in a similar way to the arm64 __put_user_error(). But that would require changing lots of callers. -- Catalin 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 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id C3755C433EF for ; Wed, 20 Oct 2021 16:37:07 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 9D5C660249 for ; Wed, 20 Oct 2021 16:37:07 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230190AbhJTQjT (ORCPT ); Wed, 20 Oct 2021 12:39:19 -0400 Received: from mail.kernel.org ([198.145.29.99]:38124 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229998AbhJTQjR (ORCPT ); Wed, 20 Oct 2021 12:39:17 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id 0616061374; Wed, 20 Oct 2021 16:36:59 +0000 (UTC) Date: Wed, 20 Oct 2021 17:36:56 +0100 From: Catalin Marinas To: Linus Torvalds Cc: Andreas Gruenbacher , Paul Mackerras , Alexander Viro , Christoph Hellwig , "Darrick J. Wong" , Jan Kara , Matthew Wilcox , cluster-devel , linux-fsdevel , Linux Kernel Mailing List , ocfs2-devel@oss.oracle.com, kvm-ppc@vger.kernel.org, linux-btrfs Subject: Re: [PATCH v8 00/17] gfs2: Fix mmap + page fault deadlocks Message-ID: References: <20211019134204.3382645-1-agruenba@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-btrfs@vger.kernel.org On Tue, Oct 19, 2021 at 05:40:13AM -1000, Linus Torvalds wrote: > On Tue, Oct 19, 2021 at 3:42 AM Andreas Gruenbacher wrote: > > * Will Catalin Marinas's work for supporting arm64 sub-page faults > > be queued behind these patches? We have an overlap in > > fault_in_[pages_]readable fault_in_[pages_]writeable, so one of > > the two patch queues will need some adjustments. > > I think that on the whole they should be developed separately, I don't > think it's going to be a particularly difficult conflict. > > That whole discussion does mean that I suspect that we'll have to > change fault_in_iov_iter_writeable() to do the "every 16 bytes" or > whatever thing, and make it use an actual atomic "add zero" or > whatever rather than walk the page tables. But that's a conceptually > separate discussion from this one, I wouldn't actually want to mix up > the two issues too much. I agree we shouldn't mix the two at the moment. The MTE fix requires some more thinking and it's not 5.16 material yet. The atomic "add zero" trick isn't that simple for MTE since the arm64 atomic or exclusive instructions run with kernel privileges and therefore with the kernel tag checking mode. We could toggle the mode to match user's just for those atomic ops but it will make this probing even more expensive (though normally it's done on the slow path). The quick/backportable fix for MTE is probably to just disable tag checking on user addresses during pagefault_disabled(). As I mentioned in the other thread, a more elaborate fix I think is to change the uaccess routines to update an error code somewhere in a similar way to the arm64 __put_user_error(). But that would require changing lots of callers. -- Catalin 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 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 2332DC433EF for ; Wed, 20 Oct 2021 16:37:14 +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 B132161354 for ; Wed, 20 Oct 2021 16:37:13 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org B132161354 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=arm.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=oss.oracle.com Received: from pps.filterd (m0246632.ppops.net [127.0.0.1]) by mx0b-00069f02.pphosted.com (8.16.1.2/8.16.1.2) with SMTP id 19KG7XlW003722; Wed, 20 Oct 2021 16:37:12 GMT Received: from userp3030.oracle.com (userp3030.oracle.com [156.151.31.80]) by mx0b-00069f02.pphosted.com with ESMTP id 3bsr45a8y4-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 20 Oct 2021 16:37:11 +0000 Received: from pps.filterd (userp3030.oracle.com [127.0.0.1]) by userp3030.oracle.com (8.16.1.2/8.16.1.2) with SMTP id 19KGZY7d068212; Wed, 20 Oct 2021 16:37:10 GMT Received: from oss.oracle.com (oss-old-reserved.oracle.com [137.254.22.2]) by userp3030.oracle.com with ESMTP id 3bqkv0bfxp-1 (version=TLSv1 cipher=AES256-SHA bits=256 verify=NO); Wed, 20 Oct 2021 16:37:10 +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 1mdEaT-0003s6-NT; Wed, 20 Oct 2021 09:37:09 -0700 Received: from userp3020.oracle.com ([156.151.31.79]) by oss.oracle.com with esmtp (Exim 4.63) (envelope-from ) id 1mdEaP-0003rg-Fr for ocfs2-devel@oss.oracle.com; Wed, 20 Oct 2021 09:37:05 -0700 Received: from pps.filterd (userp3020.oracle.com [127.0.0.1]) by userp3020.oracle.com (8.16.1.2/8.16.1.2) with SMTP id 19KGZZZ6013707 for ; Wed, 20 Oct 2021 16:37:05 GMT Received: from mx0a-00069f01.pphosted.com (mx0a-00069f01.pphosted.com [205.220.165.26]) by userp3020.oracle.com with ESMTP id 3br8guer7a-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Wed, 20 Oct 2021 16:37:05 +0000 Received: from pps.filterd (m0246575.ppops.net [127.0.0.1]) by mx0b-00069f01.pphosted.com (8.16.1.2/8.16.1.2) with SMTP id 19KC6m5M010948 for ; Wed, 20 Oct 2021 16:37:03 GMT Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by mx0b-00069f01.pphosted.com with ESMTP id 3btcpgg9u8-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Wed, 20 Oct 2021 16:37:03 +0000 Received: by mail.kernel.org (Postfix) with ESMTPSA id 0616061374; Wed, 20 Oct 2021 16:36:59 +0000 (UTC) Date: Wed, 20 Oct 2021 17:36:56 +0100 From: Catalin Marinas To: Linus Torvalds Message-ID: References: <20211019134204.3382645-1-agruenba@redhat.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-Source-IP: 198.145.29.99 X-ServerName: mail.kernel.org X-Proofpoint-SPF-Result: pass X-Proofpoint-SPF-Record: v=spf1 mx include:_spf.kernel.org ~all X-Proofpoint-Virus-Version: vendor=nai engine=6300 definitions=10143 signatures=668683 X-Proofpoint-Spam-Reason: safe X-Spam: OrgSafeList X-SpamRule: orgsafelist Cc: kvm-ppc@vger.kernel.org, Christoph Hellwig , cluster-devel , Jan Kara , Andreas Gruenbacher , Linux Kernel Mailing List , Paul Mackerras , Alexander Viro , linux-fsdevel , linux-btrfs , ocfs2-devel@oss.oracle.com Subject: Re: [Ocfs2-devel] [PATCH v8 00/17] gfs2: Fix mmap + page fault deadlocks 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=6300 definitions=10143 signatures=668683 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxlogscore=999 suspectscore=0 malwarescore=0 bulkscore=0 phishscore=0 adultscore=0 spamscore=0 mlxscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2109230001 definitions=main-2110200092 X-Proofpoint-ORIG-GUID: LCEstIBUEsQRMQuTz1fFj6fRITTzaq3U X-Proofpoint-GUID: LCEstIBUEsQRMQuTz1fFj6fRITTzaq3U On Tue, Oct 19, 2021 at 05:40:13AM -1000, Linus Torvalds wrote: > On Tue, Oct 19, 2021 at 3:42 AM Andreas Gruenbacher wrote: > > * Will Catalin Marinas's work for supporting arm64 sub-page faults > > be queued behind these patches? We have an overlap in > > fault_in_[pages_]readable fault_in_[pages_]writeable, so one of > > the two patch queues will need some adjustments. > > I think that on the whole they should be developed separately, I don't > think it's going to be a particularly difficult conflict. > > That whole discussion does mean that I suspect that we'll have to > change fault_in_iov_iter_writeable() to do the "every 16 bytes" or > whatever thing, and make it use an actual atomic "add zero" or > whatever rather than walk the page tables. But that's a conceptually > separate discussion from this one, I wouldn't actually want to mix up > the two issues too much. I agree we shouldn't mix the two at the moment. The MTE fix requires some more thinking and it's not 5.16 material yet. The atomic "add zero" trick isn't that simple for MTE since the arm64 atomic or exclusive instructions run with kernel privileges and therefore with the kernel tag checking mode. We could toggle the mode to match user's just for those atomic ops but it will make this probing even more expensive (though normally it's done on the slow path). The quick/backportable fix for MTE is probably to just disable tag checking on user addresses during pagefault_disabled(). As I mentioned in the other thread, a more elaborate fix I think is to change the uaccess routines to update an error code somewhere in a similar way to the arm64 __put_user_error(). But that would require changing lots of callers. -- Catalin _______________________________________________ Ocfs2-devel mailing list Ocfs2-devel@oss.oracle.com https://oss.oracle.com/mailman/listinfo/ocfs2-devel