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.2 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_2 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 982E9C43461 for ; Tue, 8 Sep 2020 19:58:23 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 4FDA420658 for ; Tue, 8 Sep 2020 19:58:23 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=ibm.com header.i=@ibm.com header.b="VYO3+yMy" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1732580AbgIHT6V (ORCPT ); Tue, 8 Sep 2020 15:58:21 -0400 Received: from mx0a-001b2d01.pphosted.com ([148.163.156.1]:44510 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730377AbgIHPfq (ORCPT ); Tue, 8 Sep 2020 11:35:46 -0400 Received: from pps.filterd (m0098394.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 088DXjY1185320; Tue, 8 Sep 2020 09:39:07 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ibm.com; h=date : from : to : cc : subject : message-id : in-reply-to : references : mime-version : content-type : content-transfer-encoding; s=pp1; bh=XDC5FoG+KgqujaeAyg7l2gVOSzxylPnVZ4pvoUk44a4=; b=VYO3+yMyhC4rNfbvQWVAf5wbndHjAv0y1eUtuG+dUlXfVqTQtsPZvyeD2EVRCQwQQ0wd TutpfKWEHZoLzIbERiftaWVuVc99voCzqPxTVSB9+YrYy6euMilc2SV3S3+AUJEHZzl6 ihNPJWVkh4bcuARr0D/TtoyzkoaOoqOBTZlZVuvvVdBSZExlgcWLsmWBRCtCcScknnJM Ep2A/5wcBkn7cJ6Ezi1btOwR/nf4YJeQRUpzhpfg8FcOd6UTG4U015Ax4tass/gg39oy Rm1FvI1JyI2tuzS/qT18SDIuFSSSLeaq3wUR+ugqzw10JLi+rfH7iOYXdexSkPJLZ3eI rw== Received: from pps.reinject (localhost [127.0.0.1]) by mx0a-001b2d01.pphosted.com with ESMTP id 33e9scu0a2-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 08 Sep 2020 09:39:07 -0400 Received: from m0098394.ppops.net (m0098394.ppops.net [127.0.0.1]) by pps.reinject (8.16.0.36/8.16.0.36) with SMTP id 088DXs8j186234; Tue, 8 Sep 2020 09:39:06 -0400 Received: from ppma03fra.de.ibm.com (6b.4a.5195.ip4.static.sl-reverse.com [149.81.74.107]) by mx0a-001b2d01.pphosted.com with ESMTP id 33e9scu08p-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 08 Sep 2020 09:39:06 -0400 Received: from pps.filterd (ppma03fra.de.ibm.com [127.0.0.1]) by ppma03fra.de.ibm.com (8.16.0.42/8.16.0.42) with SMTP id 088DapAZ028999; Tue, 8 Sep 2020 13:39:03 GMT Received: from b06cxnps3074.portsmouth.uk.ibm.com (d06relay09.portsmouth.uk.ibm.com [9.149.109.194]) by ppma03fra.de.ibm.com with ESMTP id 33c2a8a4s6-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 08 Sep 2020 13:39:03 +0000 Received: from d06av21.portsmouth.uk.ibm.com (d06av21.portsmouth.uk.ibm.com [9.149.105.232]) by b06cxnps3074.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 088Dd0lD38535586 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 8 Sep 2020 13:39:00 GMT Received: from d06av21.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 5967852051; Tue, 8 Sep 2020 13:39:00 +0000 (GMT) Received: from thinkpad (unknown [9.171.25.197]) by d06av21.portsmouth.uk.ibm.com (Postfix) with SMTP id 260485204F; Tue, 8 Sep 2020 13:38:59 +0000 (GMT) Date: Tue, 8 Sep 2020 15:38:57 +0200 From: Gerald Schaefer To: Christophe Leroy Cc: Christian Borntraeger , Jason Gunthorpe , John Hubbard , Peter Zijlstra , Dave Hansen , linux-mm , Paul Mackerras , linux-sparc , Alexander Gordeev , Claudio Imbrenda , Will Deacon , linux-arch , linux-s390 , Vasily Gorbik , Richard Weinberger , linux-x86 , Russell King , Ingo Molnar , Catalin Marinas , Andrey Ryabinin , Heiko Carstens , Arnd Bergmann , Jeff Dike , linux-um , Borislav Petkov , Andy Lutomirski , Thomas Gleixner , linux-arm , linux-power , LKML , Andrew Morton , Linus Torvalds , Mike Rapoport Subject: Re: [RFC PATCH v2 1/3] mm/gup: fix gup_fast with dynamic page table folding Message-ID: <20200908153857.08d09581@thinkpad> In-Reply-To: <96b80926-cf5b-1afa-9b7a-949a2188e61f@csgroup.eu> References: <20200907180058.64880-1-gerald.schaefer@linux.ibm.com> <20200907180058.64880-2-gerald.schaefer@linux.ibm.com> <82fbe8f9-f199-5fc2-4168-eb43ad0b0346@csgroup.eu> <70a3dcb5-5ed1-6efa-6158-d0573d6927da@de.ibm.com> <96b80926-cf5b-1afa-9b7a-949a2188e61f@csgroup.eu> X-Mailer: Claws Mail 3.17.6 (GTK+ 2.24.32; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-TM-AS-GCONF: 00 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235,18.0.687 definitions=2020-09-08_07:2020-09-08,2020-09-08 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 lowpriorityscore=0 mlxlogscore=999 bulkscore=0 suspectscore=0 clxscore=1011 adultscore=0 malwarescore=0 spamscore=0 mlxscore=0 priorityscore=1501 phishscore=0 impostorscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2006250000 definitions=main-2009080128 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 8 Sep 2020 14:40:10 +0200 Christophe Leroy wrote: >=20 >=20 > Le 08/09/2020 =C3=A0 14:09, Christian Borntraeger a =C3=A9crit=C2=A0: > >=20 > >=20 > > On 08.09.20 07:06, Christophe Leroy wrote: > >> > >> > >> Le 07/09/2020 =C3=A0 20:00, Gerald Schaefer a =C3=A9crit=C2=A0: > >>> From: Alexander Gordeev > >>> > >>> Commit 1a42010cdc26 ("s390/mm: convert to the generic get_user_pages_= fast > >>> code") introduced a subtle but severe bug on s390 with gup_fast, due = to > >>> dynamic page table folding. > >>> > >>> The question "What would it require for the generic code to work for = s390" > >>> has already been discussed here > >>> https://lkml.kernel.org/r/20190418100218.0a4afd51@mschwideX1 > >>> and ended with a promising approach here > >>> https://lkml.kernel.org/r/20190419153307.4f2911b5@mschwideX1 > >>> which in the end unfortunately didn't quite work completely. > >>> > >>> We tried to mimic static level folding by changing pgd_offset to alwa= ys > >>> calculate top level page table offset, and do nothing in folded pXd_o= ffset. > >>> What has been overlooked is that PxD_SIZE/MASK and thus pXd_addr_end = do > >>> not reflect this dynamic behaviour, and still act like static 5-level > >>> page tables. > >>> > >> > >> [...] > >> > >>> > >>> Fix this by introducing new pXd_addr_end_folded helpers, which take an > >>> additional pXd entry value parameter, that can be used on s390 > >>> to determine the correct page table level and return corresponding > >>> end / boundary. With that, the pointer iteration will always > >>> happen in gup_pgd_range for s390. No change for other architectures > >>> introduced. > >> > >> Not sure pXd_addr_end_folded() is the best understandable name, alltho= ugh I don't have any alternative suggestion at the moment. > >> Maybe could be something like pXd_addr_end_fixup() as it will disappea= r in the next patch, or pXd_addr_end_gup() ? > >> > >> Also, if it happens to be acceptable to get patch 2 in stable, I think= you should switch patch 1 and patch 2 to avoid the step through pXd_addr_e= nd_folded() > >=20 > > given that this fixes a data corruption issue, wouldnt it be the best t= o go forward > > with this patch ASAP and then handle the other patches on top with all = the time that > > we need? >=20 > I have no strong opinion on this, but I feel rather tricky to have to=20 > change generic part of GUP to use a new fonction then revert that change= =20 > in the following patch, just because you want the first patch in stable=20 > and not the second one. >=20 > Regardless, I was wondering, why do we need a reference to the pXd at=20 > all when calling pXd_addr_end() ? >=20 > Couldn't S390 retrieve the pXd by using the pXd_offset() dance with the=20 > passed addr ? Apart from performance impact when re-doing that what has already been done by the caller, I think we would also break the READ_ONCE semantics. After all, the pXd_offset() would also require some pXd pointer input, which we don't have. So we would need to start over again from mm->pgd. Also, it seems to be more in line with other primitives that take a pXd value or pointer. From mboxrd@z Thu Jan 1 00:00:00 1970 From: Gerald Schaefer Date: Tue, 08 Sep 2020 13:38:57 +0000 Subject: Re: [RFC PATCH v2 1/3] mm/gup: fix gup_fast with dynamic page table folding Message-Id: <20200908153857.08d09581@thinkpad> List-Id: References: <20200907180058.64880-1-gerald.schaefer@linux.ibm.com> <20200907180058.64880-2-gerald.schaefer@linux.ibm.com> <82fbe8f9-f199-5fc2-4168-eb43ad0b0346@csgroup.eu> <70a3dcb5-5ed1-6efa-6158-d0573d6927da@de.ibm.com> <96b80926-cf5b-1afa-9b7a-949a2188e61f@csgroup.eu> In-Reply-To: <96b80926-cf5b-1afa-9b7a-949a2188e61f@csgroup.eu> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit To: Christophe Leroy Cc: Christian Borntraeger , Jason Gunthorpe , John Hubbard , Peter Zijlstra , Dave Hansen , linux-mm , Paul Mackerras , linux-sparc , Alexander Gordeev , Claudio Imbrenda , Will Deacon , linux-arch , linux-s390 , Vasily Gorbik , Richard Weinberger , linux-x86 , Russell King , Ingo Molnar , Catalin Marinas , Andrey Ryabinin , Heiko Carstens , Arnd Bergmann , Jeff Dike , linux-um , Borislav Petkov , Andy Lutomirski , Thomas Gleixner , linux-arm , linux-power , LKML , Andrew Morton , Linus Torvalds , Mike Rapoport On Tue, 8 Sep 2020 14:40:10 +0200 Christophe Leroy wrote: > > > Le 08/09/2020 à 14:09, Christian Borntraeger a écrit : > > > > > > On 08.09.20 07:06, Christophe Leroy wrote: > >> > >> > >> Le 07/09/2020 à 20:00, Gerald Schaefer a écrit : > >>> From: Alexander Gordeev > >>> > >>> Commit 1a42010cdc26 ("s390/mm: convert to the generic get_user_pages_fast > >>> code") introduced a subtle but severe bug on s390 with gup_fast, due to > >>> dynamic page table folding. > >>> > >>> The question "What would it require for the generic code to work for s390" > >>> has already been discussed here > >>> https://lkml.kernel.org/r/20190418100218.0a4afd51@mschwideX1 > >>> and ended with a promising approach here > >>> https://lkml.kernel.org/r/20190419153307.4f2911b5@mschwideX1 > >>> which in the end unfortunately didn't quite work completely. > >>> > >>> We tried to mimic static level folding by changing pgd_offset to always > >>> calculate top level page table offset, and do nothing in folded pXd_offset. > >>> What has been overlooked is that PxD_SIZE/MASK and thus pXd_addr_end do > >>> not reflect this dynamic behaviour, and still act like static 5-level > >>> page tables. > >>> > >> > >> [...] > >> > >>> > >>> Fix this by introducing new pXd_addr_end_folded helpers, which take an > >>> additional pXd entry value parameter, that can be used on s390 > >>> to determine the correct page table level and return corresponding > >>> end / boundary. With that, the pointer iteration will always > >>> happen in gup_pgd_range for s390. No change for other architectures > >>> introduced. > >> > >> Not sure pXd_addr_end_folded() is the best understandable name, allthough I don't have any alternative suggestion at the moment. > >> Maybe could be something like pXd_addr_end_fixup() as it will disappear in the next patch, or pXd_addr_end_gup() ? > >> > >> Also, if it happens to be acceptable to get patch 2 in stable, I think you should switch patch 1 and patch 2 to avoid the step through pXd_addr_end_folded() > > > > given that this fixes a data corruption issue, wouldnt it be the best to go forward > > with this patch ASAP and then handle the other patches on top with all the time that > > we need? > > I have no strong opinion on this, but I feel rather tricky to have to > change generic part of GUP to use a new fonction then revert that change > in the following patch, just because you want the first patch in stable > and not the second one. > > Regardless, I was wondering, why do we need a reference to the pXd at > all when calling pXd_addr_end() ? > > Couldn't S390 retrieve the pXd by using the pXd_offset() dance with the > passed addr ? Apart from performance impact when re-doing that what has already been done by the caller, I think we would also break the READ_ONCE semantics. After all, the pXd_offset() would also require some pXd pointer input, which we don't have. So we would need to start over again from mm->pgd. Also, it seems to be more in line with other primitives that take a pXd value or pointer. 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.0 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_2 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 99EEBC43461 for ; Tue, 8 Sep 2020 13:42:42 +0000 (UTC) Received: from lists.ozlabs.org (lists.ozlabs.org [203.11.71.2]) (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 9D2322078E for ; Tue, 8 Sep 2020 13:42:41 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=ibm.com header.i=@ibm.com header.b="VYO3+yMy" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 9D2322078E Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linux.ibm.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Received: from bilbo.ozlabs.org (lists.ozlabs.org [IPv6:2401:3900:2:1::3]) by lists.ozlabs.org (Postfix) with ESMTP id 4Bm5tk4g5qzDqRF for ; Tue, 8 Sep 2020 23:42:38 +1000 (AEST) Authentication-Results: lists.ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=linux.ibm.com (client-ip=148.163.156.1; helo=mx0a-001b2d01.pphosted.com; envelope-from=gerald.schaefer@linux.ibm.com; receiver=) Authentication-Results: lists.ozlabs.org; dmarc=pass (p=none dis=none) header.from=linux.ibm.com Authentication-Results: lists.ozlabs.org; dkim=pass (2048-bit key; unprotected) header.d=ibm.com header.i=@ibm.com header.a=rsa-sha256 header.s=pp1 header.b=VYO3+yMy; dkim-atps=neutral Received: from mx0a-001b2d01.pphosted.com (mx0a-001b2d01.pphosted.com [148.163.156.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 4Bm5qS75NLzDqQF for ; Tue, 8 Sep 2020 23:39:48 +1000 (AEST) Received: from pps.filterd (m0098394.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 088DXjY1185320; Tue, 8 Sep 2020 09:39:07 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ibm.com; h=date : from : to : cc : subject : message-id : in-reply-to : references : mime-version : content-type : content-transfer-encoding; s=pp1; bh=XDC5FoG+KgqujaeAyg7l2gVOSzxylPnVZ4pvoUk44a4=; b=VYO3+yMyhC4rNfbvQWVAf5wbndHjAv0y1eUtuG+dUlXfVqTQtsPZvyeD2EVRCQwQQ0wd TutpfKWEHZoLzIbERiftaWVuVc99voCzqPxTVSB9+YrYy6euMilc2SV3S3+AUJEHZzl6 ihNPJWVkh4bcuARr0D/TtoyzkoaOoqOBTZlZVuvvVdBSZExlgcWLsmWBRCtCcScknnJM Ep2A/5wcBkn7cJ6Ezi1btOwR/nf4YJeQRUpzhpfg8FcOd6UTG4U015Ax4tass/gg39oy Rm1FvI1JyI2tuzS/qT18SDIuFSSSLeaq3wUR+ugqzw10JLi+rfH7iOYXdexSkPJLZ3eI rw== Received: from pps.reinject (localhost [127.0.0.1]) by mx0a-001b2d01.pphosted.com with ESMTP id 33e9scu0a2-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 08 Sep 2020 09:39:07 -0400 Received: from m0098394.ppops.net (m0098394.ppops.net [127.0.0.1]) by pps.reinject (8.16.0.36/8.16.0.36) with SMTP id 088DXs8j186234; Tue, 8 Sep 2020 09:39:06 -0400 Received: from ppma03fra.de.ibm.com (6b.4a.5195.ip4.static.sl-reverse.com [149.81.74.107]) by mx0a-001b2d01.pphosted.com with ESMTP id 33e9scu08p-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 08 Sep 2020 09:39:06 -0400 Received: from pps.filterd (ppma03fra.de.ibm.com [127.0.0.1]) by ppma03fra.de.ibm.com (8.16.0.42/8.16.0.42) with SMTP id 088DapAZ028999; Tue, 8 Sep 2020 13:39:03 GMT Received: from b06cxnps3074.portsmouth.uk.ibm.com (d06relay09.portsmouth.uk.ibm.com [9.149.109.194]) by ppma03fra.de.ibm.com with ESMTP id 33c2a8a4s6-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 08 Sep 2020 13:39:03 +0000 Received: from d06av21.portsmouth.uk.ibm.com (d06av21.portsmouth.uk.ibm.com [9.149.105.232]) by b06cxnps3074.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 088Dd0lD38535586 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 8 Sep 2020 13:39:00 GMT Received: from d06av21.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 5967852051; Tue, 8 Sep 2020 13:39:00 +0000 (GMT) Received: from thinkpad (unknown [9.171.25.197]) by d06av21.portsmouth.uk.ibm.com (Postfix) with SMTP id 260485204F; Tue, 8 Sep 2020 13:38:59 +0000 (GMT) Date: Tue, 8 Sep 2020 15:38:57 +0200 From: Gerald Schaefer To: Christophe Leroy Subject: Re: [RFC PATCH v2 1/3] mm/gup: fix gup_fast with dynamic page table folding Message-ID: <20200908153857.08d09581@thinkpad> In-Reply-To: <96b80926-cf5b-1afa-9b7a-949a2188e61f@csgroup.eu> References: <20200907180058.64880-1-gerald.schaefer@linux.ibm.com> <20200907180058.64880-2-gerald.schaefer@linux.ibm.com> <82fbe8f9-f199-5fc2-4168-eb43ad0b0346@csgroup.eu> <70a3dcb5-5ed1-6efa-6158-d0573d6927da@de.ibm.com> <96b80926-cf5b-1afa-9b7a-949a2188e61f@csgroup.eu> X-Mailer: Claws Mail 3.17.6 (GTK+ 2.24.32; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-TM-AS-GCONF: 00 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-09-08_07:2020-09-08, 2020-09-08 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 lowpriorityscore=0 mlxlogscore=999 bulkscore=0 suspectscore=0 clxscore=1011 adultscore=0 malwarescore=0 spamscore=0 mlxscore=0 priorityscore=1501 phishscore=0 impostorscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2006250000 definitions=main-2009080128 X-BeenThere: linuxppc-dev@lists.ozlabs.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Peter Zijlstra , Catalin Marinas , Dave Hansen , linux-mm , Paul Mackerras , linux-sparc , Alexander Gordeev , Claudio Imbrenda , Will Deacon , linux-arch , linux-s390 , Vasily Gorbik , Christian Borntraeger , Richard Weinberger , linux-x86 , Russell King , Jason Gunthorpe , Ingo Molnar , Andrey Ryabinin , Jeff Dike , Arnd Bergmann , John Hubbard , Heiko Carstens , linux-um , Borislav Petkov , Andy Lutomirski , Thomas Gleixner , linux-arm , Linus Torvalds , LKML , Andrew Morton , linux-power , Mike Rapoport Errors-To: linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Sender: "Linuxppc-dev" On Tue, 8 Sep 2020 14:40:10 +0200 Christophe Leroy wrote: >=20 >=20 > Le 08/09/2020 =C3=A0 14:09, Christian Borntraeger a =C3=A9crit=C2=A0: > >=20 > >=20 > > On 08.09.20 07:06, Christophe Leroy wrote: > >> > >> > >> Le 07/09/2020 =C3=A0 20:00, Gerald Schaefer a =C3=A9crit=C2=A0: > >>> From: Alexander Gordeev > >>> > >>> Commit 1a42010cdc26 ("s390/mm: convert to the generic get_user_pages_= fast > >>> code") introduced a subtle but severe bug on s390 with gup_fast, due = to > >>> dynamic page table folding. > >>> > >>> The question "What would it require for the generic code to work for = s390" > >>> has already been discussed here > >>> https://lkml.kernel.org/r/20190418100218.0a4afd51@mschwideX1 > >>> and ended with a promising approach here > >>> https://lkml.kernel.org/r/20190419153307.4f2911b5@mschwideX1 > >>> which in the end unfortunately didn't quite work completely. > >>> > >>> We tried to mimic static level folding by changing pgd_offset to alwa= ys > >>> calculate top level page table offset, and do nothing in folded pXd_o= ffset. > >>> What has been overlooked is that PxD_SIZE/MASK and thus pXd_addr_end = do > >>> not reflect this dynamic behaviour, and still act like static 5-level > >>> page tables. > >>> > >> > >> [...] > >> > >>> > >>> Fix this by introducing new pXd_addr_end_folded helpers, which take an > >>> additional pXd entry value parameter, that can be used on s390 > >>> to determine the correct page table level and return corresponding > >>> end / boundary. With that, the pointer iteration will always > >>> happen in gup_pgd_range for s390. No change for other architectures > >>> introduced. > >> > >> Not sure pXd_addr_end_folded() is the best understandable name, alltho= ugh I don't have any alternative suggestion at the moment. > >> Maybe could be something like pXd_addr_end_fixup() as it will disappea= r in the next patch, or pXd_addr_end_gup() ? > >> > >> Also, if it happens to be acceptable to get patch 2 in stable, I think= you should switch patch 1 and patch 2 to avoid the step through pXd_addr_e= nd_folded() > >=20 > > given that this fixes a data corruption issue, wouldnt it be the best t= o go forward > > with this patch ASAP and then handle the other patches on top with all = the time that > > we need? >=20 > I have no strong opinion on this, but I feel rather tricky to have to=20 > change generic part of GUP to use a new fonction then revert that change= =20 > in the following patch, just because you want the first patch in stable=20 > and not the second one. >=20 > Regardless, I was wondering, why do we need a reference to the pXd at=20 > all when calling pXd_addr_end() ? >=20 > Couldn't S390 retrieve the pXd by using the pXd_offset() dance with the=20 > passed addr ? Apart from performance impact when re-doing that what has already been done by the caller, I think we would also break the READ_ONCE semantics. After all, the pXd_offset() would also require some pXd pointer input, which we don't have. So we would need to start over again from mm->pgd. Also, it seems to be more in line with other primitives that take a pXd value or pointer. 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.3 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_2 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 529EEC43461 for ; Tue, 8 Sep 2020 13:41:42 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (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 E2E792078B for ; Tue, 8 Sep 2020 13:41:41 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="Yk2tZ6CQ"; dkim=fail reason="signature verification failed" (2048-bit key) header.d=ibm.com header.i=@ibm.com header.b="VYO3+yMy" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org E2E792078B Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linux.ibm.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:MIME-Version:References:In-Reply-To:Message-ID: Subject:To:From:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=VazgMkgjGBCnN8oJC+08ExcP60ddf+AHTDHuXUeO5G8=; b=Yk2tZ6CQIe4q9mXIvcrFgr+nE MVOX+seCWppVB+pNkxU1qdHr7jlEBSgI8ae/f+H6QkoRX3uB5zQAjUbCHlwCIRydjsmb8rXhflEhn bmQ6uv1az36zdGNJGcGmuHxct6UbJ31ETip40AUQ5snlHESKXMLo7cOrb0eryOMKgTRAecOlHxor9 S2MFmhRLBvVOtUWZaGGLnc0MdlglM8ZMhzt3YldFu3EBPaz6fWMUcD0BPVodo9D4l+a7r3yR8/ws/ gPCOSadAk0Ot8R82LVtme5GYoZ2vN0TukcoG2QKQV41cqUMVl0cKEsTq6E2BCBkkn8MO4+k+RM29l 9/In2gbbg==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kFdqc-00045O-S3; Tue, 08 Sep 2020 13:39:46 +0000 Received: from mx0a-001b2d01.pphosted.com ([148.163.156.1]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1kFdqa-00044o-P5; Tue, 08 Sep 2020 13:39:45 +0000 Received: from pps.filterd (m0098394.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 088DXjY1185320; Tue, 8 Sep 2020 09:39:07 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ibm.com; h=date : from : to : cc : subject : message-id : in-reply-to : references : mime-version : content-type : content-transfer-encoding; s=pp1; bh=XDC5FoG+KgqujaeAyg7l2gVOSzxylPnVZ4pvoUk44a4=; b=VYO3+yMyhC4rNfbvQWVAf5wbndHjAv0y1eUtuG+dUlXfVqTQtsPZvyeD2EVRCQwQQ0wd TutpfKWEHZoLzIbERiftaWVuVc99voCzqPxTVSB9+YrYy6euMilc2SV3S3+AUJEHZzl6 ihNPJWVkh4bcuARr0D/TtoyzkoaOoqOBTZlZVuvvVdBSZExlgcWLsmWBRCtCcScknnJM Ep2A/5wcBkn7cJ6Ezi1btOwR/nf4YJeQRUpzhpfg8FcOd6UTG4U015Ax4tass/gg39oy Rm1FvI1JyI2tuzS/qT18SDIuFSSSLeaq3wUR+ugqzw10JLi+rfH7iOYXdexSkPJLZ3eI rw== Received: from pps.reinject (localhost [127.0.0.1]) by mx0a-001b2d01.pphosted.com with ESMTP id 33e9scu0a2-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 08 Sep 2020 09:39:07 -0400 Received: from m0098394.ppops.net (m0098394.ppops.net [127.0.0.1]) by pps.reinject (8.16.0.36/8.16.0.36) with SMTP id 088DXs8j186234; Tue, 8 Sep 2020 09:39:06 -0400 Received: from ppma03fra.de.ibm.com (6b.4a.5195.ip4.static.sl-reverse.com [149.81.74.107]) by mx0a-001b2d01.pphosted.com with ESMTP id 33e9scu08p-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 08 Sep 2020 09:39:06 -0400 Received: from pps.filterd (ppma03fra.de.ibm.com [127.0.0.1]) by ppma03fra.de.ibm.com (8.16.0.42/8.16.0.42) with SMTP id 088DapAZ028999; Tue, 8 Sep 2020 13:39:03 GMT Received: from b06cxnps3074.portsmouth.uk.ibm.com (d06relay09.portsmouth.uk.ibm.com [9.149.109.194]) by ppma03fra.de.ibm.com with ESMTP id 33c2a8a4s6-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 08 Sep 2020 13:39:03 +0000 Received: from d06av21.portsmouth.uk.ibm.com (d06av21.portsmouth.uk.ibm.com [9.149.105.232]) by b06cxnps3074.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 088Dd0lD38535586 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 8 Sep 2020 13:39:00 GMT Received: from d06av21.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 5967852051; Tue, 8 Sep 2020 13:39:00 +0000 (GMT) Received: from thinkpad (unknown [9.171.25.197]) by d06av21.portsmouth.uk.ibm.com (Postfix) with SMTP id 260485204F; Tue, 8 Sep 2020 13:38:59 +0000 (GMT) Date: Tue, 8 Sep 2020 15:38:57 +0200 From: Gerald Schaefer To: Christophe Leroy Subject: Re: [RFC PATCH v2 1/3] mm/gup: fix gup_fast with dynamic page table folding Message-ID: <20200908153857.08d09581@thinkpad> In-Reply-To: <96b80926-cf5b-1afa-9b7a-949a2188e61f@csgroup.eu> References: <20200907180058.64880-1-gerald.schaefer@linux.ibm.com> <20200907180058.64880-2-gerald.schaefer@linux.ibm.com> <82fbe8f9-f199-5fc2-4168-eb43ad0b0346@csgroup.eu> <70a3dcb5-5ed1-6efa-6158-d0573d6927da@de.ibm.com> <96b80926-cf5b-1afa-9b7a-949a2188e61f@csgroup.eu> X-Mailer: Claws Mail 3.17.6 (GTK+ 2.24.32; x86_64-redhat-linux-gnu) MIME-Version: 1.0 X-TM-AS-GCONF: 00 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-09-08_07:2020-09-08, 2020-09-08 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 lowpriorityscore=0 mlxlogscore=999 bulkscore=0 suspectscore=0 clxscore=1011 adultscore=0 malwarescore=0 spamscore=0 mlxscore=0 priorityscore=1501 phishscore=0 impostorscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2006250000 definitions=main-2009080128 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200908_093944_947562_D7A21542 X-CRM114-Status: GOOD ( 36.44 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Peter Zijlstra , Catalin Marinas , Dave Hansen , linux-mm , Paul Mackerras , linux-sparc , Alexander Gordeev , Claudio Imbrenda , Will Deacon , linux-arch , linux-s390 , Vasily Gorbik , Christian Borntraeger , Richard Weinberger , linux-x86 , Russell King , Jason Gunthorpe , Ingo Molnar , Andrey Ryabinin , Jeff Dike , Arnd Bergmann , John Hubbard , Heiko Carstens , linux-um , Borislav Petkov , Andy Lutomirski , Thomas Gleixner , linux-arm , Linus Torvalds , LKML , Andrew Morton , linux-power , Mike Rapoport Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org T24gVHVlLCA4IFNlcCAyMDIwIDE0OjQwOjEwICswMjAwCkNocmlzdG9waGUgTGVyb3kgPGNocmlz dG9waGUubGVyb3lAY3Nncm91cC5ldT4gd3JvdGU6Cgo+IAo+IAo+IExlIDA4LzA5LzIwMjAgw6Ag MTQ6MDksIENocmlzdGlhbiBCb3JudHJhZWdlciBhIMOpY3JpdMKgOgo+ID4gCj4gPiAKPiA+IE9u IDA4LjA5LjIwIDA3OjA2LCBDaHJpc3RvcGhlIExlcm95IHdyb3RlOgo+ID4+Cj4gPj4KPiA+PiBM ZSAwNy8wOS8yMDIwIMOgIDIwOjAwLCBHZXJhbGQgU2NoYWVmZXIgYSDDqWNyaXTCoDoKPiA+Pj4g RnJvbTogQWxleGFuZGVyIEdvcmRlZXYgPGFnb3JkZWV2QGxpbnV4LmlibS5jb20+Cj4gPj4+Cj4g Pj4+IENvbW1pdCAxYTQyMDEwY2RjMjYgKCJzMzkwL21tOiBjb252ZXJ0IHRvIHRoZSBnZW5lcmlj IGdldF91c2VyX3BhZ2VzX2Zhc3QKPiA+Pj4gY29kZSIpIGludHJvZHVjZWQgYSBzdWJ0bGUgYnV0 IHNldmVyZSBidWcgb24gczM5MCB3aXRoIGd1cF9mYXN0LCBkdWUgdG8KPiA+Pj4gZHluYW1pYyBw YWdlIHRhYmxlIGZvbGRpbmcuCj4gPj4+Cj4gPj4+IFRoZSBxdWVzdGlvbiAiV2hhdCB3b3VsZCBp dCByZXF1aXJlIGZvciB0aGUgZ2VuZXJpYyBjb2RlIHRvIHdvcmsgZm9yIHMzOTAiCj4gPj4+IGhh cyBhbHJlYWR5IGJlZW4gZGlzY3Vzc2VkIGhlcmUKPiA+Pj4gaHR0cHM6Ly9sa21sLmtlcm5lbC5v cmcvci8yMDE5MDQxODEwMDIxOC4wYTRhZmQ1MUBtc2Nod2lkZVgxCj4gPj4+IGFuZCBlbmRlZCB3 aXRoIGEgcHJvbWlzaW5nIGFwcHJvYWNoIGhlcmUKPiA+Pj4gaHR0cHM6Ly9sa21sLmtlcm5lbC5v cmcvci8yMDE5MDQxOTE1MzMwNy40ZjI5MTFiNUBtc2Nod2lkZVgxCj4gPj4+IHdoaWNoIGluIHRo ZSBlbmQgdW5mb3J0dW5hdGVseSBkaWRuJ3QgcXVpdGUgd29yayBjb21wbGV0ZWx5Lgo+ID4+Pgo+ ID4+PiBXZSB0cmllZCB0byBtaW1pYyBzdGF0aWMgbGV2ZWwgZm9sZGluZyBieSBjaGFuZ2luZyBw Z2Rfb2Zmc2V0IHRvIGFsd2F5cwo+ID4+PiBjYWxjdWxhdGUgdG9wIGxldmVsIHBhZ2UgdGFibGUg b2Zmc2V0LCBhbmQgZG8gbm90aGluZyBpbiBmb2xkZWQgcFhkX29mZnNldC4KPiA+Pj4gV2hhdCBo YXMgYmVlbiBvdmVybG9va2VkIGlzIHRoYXQgUHhEX1NJWkUvTUFTSyBhbmQgdGh1cyBwWGRfYWRk cl9lbmQgZG8KPiA+Pj4gbm90IHJlZmxlY3QgdGhpcyBkeW5hbWljIGJlaGF2aW91ciwgYW5kIHN0 aWxsIGFjdCBsaWtlIHN0YXRpYyA1LWxldmVsCj4gPj4+IHBhZ2UgdGFibGVzLgo+ID4+Pgo+ID4+ Cj4gPj4gWy4uLl0KPiA+Pgo+ID4+Pgo+ID4+PiBGaXggdGhpcyBieSBpbnRyb2R1Y2luZyBuZXcg cFhkX2FkZHJfZW5kX2ZvbGRlZCBoZWxwZXJzLCB3aGljaCB0YWtlIGFuCj4gPj4+IGFkZGl0aW9u YWwgcFhkIGVudHJ5IHZhbHVlIHBhcmFtZXRlciwgdGhhdCBjYW4gYmUgdXNlZCBvbiBzMzkwCj4g Pj4+IHRvIGRldGVybWluZSB0aGUgY29ycmVjdCBwYWdlIHRhYmxlIGxldmVsIGFuZCByZXR1cm4g Y29ycmVzcG9uZGluZwo+ID4+PiBlbmQgLyBib3VuZGFyeS4gV2l0aCB0aGF0LCB0aGUgcG9pbnRl ciBpdGVyYXRpb24gd2lsbCBhbHdheXMKPiA+Pj4gaGFwcGVuIGluIGd1cF9wZ2RfcmFuZ2UgZm9y IHMzOTAuIE5vIGNoYW5nZSBmb3Igb3RoZXIgYXJjaGl0ZWN0dXJlcwo+ID4+PiBpbnRyb2R1Y2Vk Lgo+ID4+Cj4gPj4gTm90IHN1cmUgcFhkX2FkZHJfZW5kX2ZvbGRlZCgpIGlzIHRoZSBiZXN0IHVu ZGVyc3RhbmRhYmxlIG5hbWUsIGFsbHRob3VnaCBJIGRvbid0IGhhdmUgYW55IGFsdGVybmF0aXZl IHN1Z2dlc3Rpb24gYXQgdGhlIG1vbWVudC4KPiA+PiBNYXliZSBjb3VsZCBiZSBzb21ldGhpbmcg bGlrZSBwWGRfYWRkcl9lbmRfZml4dXAoKSBhcyBpdCB3aWxsIGRpc2FwcGVhciBpbiB0aGUgbmV4 dCBwYXRjaCwgb3IgcFhkX2FkZHJfZW5kX2d1cCgpID8KPiA+Pgo+ID4+IEFsc28sIGlmIGl0IGhh cHBlbnMgdG8gYmUgYWNjZXB0YWJsZSB0byBnZXQgcGF0Y2ggMiBpbiBzdGFibGUsIEkgdGhpbmsg eW91IHNob3VsZCBzd2l0Y2ggcGF0Y2ggMSBhbmQgcGF0Y2ggMiB0byBhdm9pZCB0aGUgc3RlcCB0 aHJvdWdoIHBYZF9hZGRyX2VuZF9mb2xkZWQoKQo+ID4gCj4gPiBnaXZlbiB0aGF0IHRoaXMgZml4 ZXMgYSBkYXRhIGNvcnJ1cHRpb24gaXNzdWUsIHdvdWxkbnQgaXQgYmUgdGhlIGJlc3QgdG8gZ28g Zm9yd2FyZAo+ID4gd2l0aCB0aGlzIHBhdGNoIEFTQVAgYW5kIHRoZW4gaGFuZGxlIHRoZSBvdGhl ciBwYXRjaGVzIG9uIHRvcCB3aXRoIGFsbCB0aGUgdGltZSB0aGF0Cj4gPiB3ZSBuZWVkPwo+IAo+ IEkgaGF2ZSBubyBzdHJvbmcgb3BpbmlvbiBvbiB0aGlzLCBidXQgSSBmZWVsIHJhdGhlciB0cmlj a3kgdG8gaGF2ZSB0byAKPiBjaGFuZ2UgZ2VuZXJpYyBwYXJ0IG9mIEdVUCB0byB1c2UgYSBuZXcg Zm9uY3Rpb24gdGhlbiByZXZlcnQgdGhhdCBjaGFuZ2UgCj4gaW4gdGhlIGZvbGxvd2luZyBwYXRj aCwganVzdCBiZWNhdXNlIHlvdSB3YW50IHRoZSBmaXJzdCBwYXRjaCBpbiBzdGFibGUgCj4gYW5k IG5vdCB0aGUgc2Vjb25kIG9uZS4KPiAKPiBSZWdhcmRsZXNzLCBJIHdhcyB3b25kZXJpbmcsIHdo eSBkbyB3ZSBuZWVkIGEgcmVmZXJlbmNlIHRvIHRoZSBwWGQgYXQgCj4gYWxsIHdoZW4gY2FsbGlu ZyBwWGRfYWRkcl9lbmQoKSA/Cj4gCj4gQ291bGRuJ3QgUzM5MCByZXRyaWV2ZSB0aGUgcFhkIGJ5 IHVzaW5nIHRoZSBwWGRfb2Zmc2V0KCkgZGFuY2Ugd2l0aCB0aGUgCj4gcGFzc2VkIGFkZHIgPwoK QXBhcnQgZnJvbSBwZXJmb3JtYW5jZSBpbXBhY3Qgd2hlbiByZS1kb2luZyB0aGF0IHdoYXQgaGFz IGFscmVhZHkgYmVlbgpkb25lIGJ5IHRoZSBjYWxsZXIsIEkgdGhpbmsgd2Ugd291bGQgYWxzbyBi cmVhayB0aGUgUkVBRF9PTkNFIHNlbWFudGljcy4KQWZ0ZXIgYWxsLCB0aGUgcFhkX29mZnNldCgp IHdvdWxkIGFsc28gcmVxdWlyZSBzb21lIHBYZCBwb2ludGVyIGlucHV0LAp3aGljaCB3ZSBkb24n dCBoYXZlLiBTbyB3ZSB3b3VsZCBuZWVkIHRvIHN0YXJ0IG92ZXIgYWdhaW4gZnJvbSBtbS0+cGdk LgoKQWxzbywgaXQgc2VlbXMgdG8gYmUgbW9yZSBpbiBsaW5lIHdpdGggb3RoZXIgcHJpbWl0aXZl cyB0aGF0IHRha2UKYSBwWGQgdmFsdWUgb3IgcG9pbnRlci4KCl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fCmxpbnV4LWFybS1rZXJuZWwgbWFpbGluZyBsaXN0 CmxpbnV4LWFybS1rZXJuZWxAbGlzdHMuaW5mcmFkZWFkLm9yZwpodHRwOi8vbGlzdHMuaW5mcmFk ZWFkLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2xpbnV4LWFybS1rZXJuZWwK From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Tue, 8 Sep 2020 15:38:57 +0200 From: Gerald Schaefer Subject: Re: [RFC PATCH v2 1/3] mm/gup: fix gup_fast with dynamic page table folding Message-ID: <20200908153857.08d09581@thinkpad> In-Reply-To: <96b80926-cf5b-1afa-9b7a-949a2188e61f@csgroup.eu> References: <20200907180058.64880-1-gerald.schaefer@linux.ibm.com> <20200907180058.64880-2-gerald.schaefer@linux.ibm.com> <82fbe8f9-f199-5fc2-4168-eb43ad0b0346@csgroup.eu> <70a3dcb5-5ed1-6efa-6158-d0573d6927da@de.ibm.com> <96b80926-cf5b-1afa-9b7a-949a2188e61f@csgroup.eu> MIME-Version: 1.0 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: "linux-um" Errors-To: linux-um-bounces+geert=linux-m68k.org@lists.infradead.org To: Christophe Leroy Cc: Peter Zijlstra , Catalin Marinas , Dave Hansen , linux-mm , Paul Mackerras , linux-sparc , Alexander Gordeev , Claudio Imbrenda , Will Deacon , linux-arch , linux-s390 , Vasily Gorbik , Christian Borntraeger , Richard Weinberger , linux-x86 , Russell King , Jason Gunthorpe , Ingo Molnar , Andrey Ryabinin , Jeff Dike , Arnd Bergmann , John Hubbard , Heiko Carstens , linux-um , Borislav Petkov , Andy Lutomirski , Thomas Gleixner , linux-arm , Linus Torvalds , LKML , Andrew Morton , linux-power , Mike Rapoport T24gVHVlLCA4IFNlcCAyMDIwIDE0OjQwOjEwICswMjAwCkNocmlzdG9waGUgTGVyb3kgPGNocmlz dG9waGUubGVyb3lAY3Nncm91cC5ldT4gd3JvdGU6Cgo+IAo+IAo+IExlIDA4LzA5LzIwMjAgw6Ag MTQ6MDksIENocmlzdGlhbiBCb3JudHJhZWdlciBhIMOpY3JpdMKgOgo+ID4gCj4gPiAKPiA+IE9u IDA4LjA5LjIwIDA3OjA2LCBDaHJpc3RvcGhlIExlcm95IHdyb3RlOgo+ID4+Cj4gPj4KPiA+PiBM ZSAwNy8wOS8yMDIwIMOgIDIwOjAwLCBHZXJhbGQgU2NoYWVmZXIgYSDDqWNyaXTCoDoKPiA+Pj4g RnJvbTogQWxleGFuZGVyIEdvcmRlZXYgPGFnb3JkZWV2QGxpbnV4LmlibS5jb20+Cj4gPj4+Cj4g Pj4+IENvbW1pdCAxYTQyMDEwY2RjMjYgKCJzMzkwL21tOiBjb252ZXJ0IHRvIHRoZSBnZW5lcmlj IGdldF91c2VyX3BhZ2VzX2Zhc3QKPiA+Pj4gY29kZSIpIGludHJvZHVjZWQgYSBzdWJ0bGUgYnV0 IHNldmVyZSBidWcgb24gczM5MCB3aXRoIGd1cF9mYXN0LCBkdWUgdG8KPiA+Pj4gZHluYW1pYyBw YWdlIHRhYmxlIGZvbGRpbmcuCj4gPj4+Cj4gPj4+IFRoZSBxdWVzdGlvbiAiV2hhdCB3b3VsZCBp dCByZXF1aXJlIGZvciB0aGUgZ2VuZXJpYyBjb2RlIHRvIHdvcmsgZm9yIHMzOTAiCj4gPj4+IGhh cyBhbHJlYWR5IGJlZW4gZGlzY3Vzc2VkIGhlcmUKPiA+Pj4gaHR0cHM6Ly9sa21sLmtlcm5lbC5v cmcvci8yMDE5MDQxODEwMDIxOC4wYTRhZmQ1MUBtc2Nod2lkZVgxCj4gPj4+IGFuZCBlbmRlZCB3 aXRoIGEgcHJvbWlzaW5nIGFwcHJvYWNoIGhlcmUKPiA+Pj4gaHR0cHM6Ly9sa21sLmtlcm5lbC5v cmcvci8yMDE5MDQxOTE1MzMwNy40ZjI5MTFiNUBtc2Nod2lkZVgxCj4gPj4+IHdoaWNoIGluIHRo ZSBlbmQgdW5mb3J0dW5hdGVseSBkaWRuJ3QgcXVpdGUgd29yayBjb21wbGV0ZWx5Lgo+ID4+Pgo+ ID4+PiBXZSB0cmllZCB0byBtaW1pYyBzdGF0aWMgbGV2ZWwgZm9sZGluZyBieSBjaGFuZ2luZyBw Z2Rfb2Zmc2V0IHRvIGFsd2F5cwo+ID4+PiBjYWxjdWxhdGUgdG9wIGxldmVsIHBhZ2UgdGFibGUg b2Zmc2V0LCBhbmQgZG8gbm90aGluZyBpbiBmb2xkZWQgcFhkX29mZnNldC4KPiA+Pj4gV2hhdCBo YXMgYmVlbiBvdmVybG9va2VkIGlzIHRoYXQgUHhEX1NJWkUvTUFTSyBhbmQgdGh1cyBwWGRfYWRk cl9lbmQgZG8KPiA+Pj4gbm90IHJlZmxlY3QgdGhpcyBkeW5hbWljIGJlaGF2aW91ciwgYW5kIHN0 aWxsIGFjdCBsaWtlIHN0YXRpYyA1LWxldmVsCj4gPj4+IHBhZ2UgdGFibGVzLgo+ID4+Pgo+ID4+ Cj4gPj4gWy4uLl0KPiA+Pgo+ID4+Pgo+ID4+PiBGaXggdGhpcyBieSBpbnRyb2R1Y2luZyBuZXcg cFhkX2FkZHJfZW5kX2ZvbGRlZCBoZWxwZXJzLCB3aGljaCB0YWtlIGFuCj4gPj4+IGFkZGl0aW9u YWwgcFhkIGVudHJ5IHZhbHVlIHBhcmFtZXRlciwgdGhhdCBjYW4gYmUgdXNlZCBvbiBzMzkwCj4g Pj4+IHRvIGRldGVybWluZSB0aGUgY29ycmVjdCBwYWdlIHRhYmxlIGxldmVsIGFuZCByZXR1cm4g Y29ycmVzcG9uZGluZwo+ID4+PiBlbmQgLyBib3VuZGFyeS4gV2l0aCB0aGF0LCB0aGUgcG9pbnRl ciBpdGVyYXRpb24gd2lsbCBhbHdheXMKPiA+Pj4gaGFwcGVuIGluIGd1cF9wZ2RfcmFuZ2UgZm9y IHMzOTAuIE5vIGNoYW5nZSBmb3Igb3RoZXIgYXJjaGl0ZWN0dXJlcwo+ID4+PiBpbnRyb2R1Y2Vk Lgo+ID4+Cj4gPj4gTm90IHN1cmUgcFhkX2FkZHJfZW5kX2ZvbGRlZCgpIGlzIHRoZSBiZXN0IHVu ZGVyc3RhbmRhYmxlIG5hbWUsIGFsbHRob3VnaCBJIGRvbid0IGhhdmUgYW55IGFsdGVybmF0aXZl IHN1Z2dlc3Rpb24gYXQgdGhlIG1vbWVudC4KPiA+PiBNYXliZSBjb3VsZCBiZSBzb21ldGhpbmcg bGlrZSBwWGRfYWRkcl9lbmRfZml4dXAoKSBhcyBpdCB3aWxsIGRpc2FwcGVhciBpbiB0aGUgbmV4 dCBwYXRjaCwgb3IgcFhkX2FkZHJfZW5kX2d1cCgpID8KPiA+Pgo+ID4+IEFsc28sIGlmIGl0IGhh cHBlbnMgdG8gYmUgYWNjZXB0YWJsZSB0byBnZXQgcGF0Y2ggMiBpbiBzdGFibGUsIEkgdGhpbmsg eW91IHNob3VsZCBzd2l0Y2ggcGF0Y2ggMSBhbmQgcGF0Y2ggMiB0byBhdm9pZCB0aGUgc3RlcCB0 aHJvdWdoIHBYZF9hZGRyX2VuZF9mb2xkZWQoKQo+ID4gCj4gPiBnaXZlbiB0aGF0IHRoaXMgZml4 ZXMgYSBkYXRhIGNvcnJ1cHRpb24gaXNzdWUsIHdvdWxkbnQgaXQgYmUgdGhlIGJlc3QgdG8gZ28g Zm9yd2FyZAo+ID4gd2l0aCB0aGlzIHBhdGNoIEFTQVAgYW5kIHRoZW4gaGFuZGxlIHRoZSBvdGhl ciBwYXRjaGVzIG9uIHRvcCB3aXRoIGFsbCB0aGUgdGltZSB0aGF0Cj4gPiB3ZSBuZWVkPwo+IAo+ IEkgaGF2ZSBubyBzdHJvbmcgb3BpbmlvbiBvbiB0aGlzLCBidXQgSSBmZWVsIHJhdGhlciB0cmlj a3kgdG8gaGF2ZSB0byAKPiBjaGFuZ2UgZ2VuZXJpYyBwYXJ0IG9mIEdVUCB0byB1c2UgYSBuZXcg Zm9uY3Rpb24gdGhlbiByZXZlcnQgdGhhdCBjaGFuZ2UgCj4gaW4gdGhlIGZvbGxvd2luZyBwYXRj aCwganVzdCBiZWNhdXNlIHlvdSB3YW50IHRoZSBmaXJzdCBwYXRjaCBpbiBzdGFibGUgCj4gYW5k IG5vdCB0aGUgc2Vjb25kIG9uZS4KPiAKPiBSZWdhcmRsZXNzLCBJIHdhcyB3b25kZXJpbmcsIHdo eSBkbyB3ZSBuZWVkIGEgcmVmZXJlbmNlIHRvIHRoZSBwWGQgYXQgCj4gYWxsIHdoZW4gY2FsbGlu ZyBwWGRfYWRkcl9lbmQoKSA/Cj4gCj4gQ291bGRuJ3QgUzM5MCByZXRyaWV2ZSB0aGUgcFhkIGJ5 IHVzaW5nIHRoZSBwWGRfb2Zmc2V0KCkgZGFuY2Ugd2l0aCB0aGUgCj4gcGFzc2VkIGFkZHIgPwoK QXBhcnQgZnJvbSBwZXJmb3JtYW5jZSBpbXBhY3Qgd2hlbiByZS1kb2luZyB0aGF0IHdoYXQgaGFz IGFscmVhZHkgYmVlbgpkb25lIGJ5IHRoZSBjYWxsZXIsIEkgdGhpbmsgd2Ugd291bGQgYWxzbyBi cmVhayB0aGUgUkVBRF9PTkNFIHNlbWFudGljcy4KQWZ0ZXIgYWxsLCB0aGUgcFhkX29mZnNldCgp IHdvdWxkIGFsc28gcmVxdWlyZSBzb21lIHBYZCBwb2ludGVyIGlucHV0LAp3aGljaCB3ZSBkb24n dCBoYXZlLiBTbyB3ZSB3b3VsZCBuZWVkIHRvIHN0YXJ0IG92ZXIgYWdhaW4gZnJvbSBtbS0+cGdk LgoKQWxzbywgaXQgc2VlbXMgdG8gYmUgbW9yZSBpbiBsaW5lIHdpdGggb3RoZXIgcHJpbWl0aXZl cyB0aGF0IHRha2UKYSBwWGQgdmFsdWUgb3IgcG9pbnRlci4KCl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fCmxpbnV4LXVtIG1haWxpbmcgbGlzdApsaW51eC11 bUBsaXN0cy5pbmZyYWRlYWQub3JnCmh0dHA6Ly9saXN0cy5pbmZyYWRlYWQub3JnL21haWxtYW4v bGlzdGluZm8vbGludXgtdW0K