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 B370DC433E2 for ; Tue, 8 Sep 2020 17:38:46 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 706E52087D for ; Tue, 8 Sep 2020 17:38:46 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=ibm.com header.i=@ibm.com header.b="CpOXYrIz" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1732024AbgIHRio (ORCPT ); Tue, 8 Sep 2020 13:38:44 -0400 Received: from mx0a-001b2d01.pphosted.com ([148.163.156.1]:56758 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728264AbgIHRiD (ORCPT ); Tue, 8 Sep 2020 13:38:03 -0400 Received: from pps.filterd (m0098404.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 088HX91w193873; Tue, 8 Sep 2020 13:37:02 -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=zTcPf30MWc1o3sVkuFOlszFjBszv6mbPeKxPdnXhSzU=; b=CpOXYrIzNqgah+XmLK3ao2p1ye9+BqkrW/W1vkBKNJnKCOWAruPC38o1UqN5H0fatOAw XumWZzfaC1TZGPFsow6W/myGfJbHhaD2OvuzQU0oxh2EDzoXjNHyJvsUt1Te4q4rOnxP hoH4fPXZ42JeutQXvPzj1LuseK96o+mcemAbZdpCDekWLg7A2PFNwMito9+ERwk99PLx nzqwnuOOTkECp7JT3Dm1gwXmzW5zTGO/Ua5IgYtQHrsvmvB5+rmFFLnzfuN/57SIWYYH vzeOQxBeZZr7qbY/CEExQHgWB8KAC0wqCkDbM8R27TiIV4YWSm2aGi/j8+grRA00NWav SA== Received: from pps.reinject (localhost [127.0.0.1]) by mx0a-001b2d01.pphosted.com with ESMTP id 33edqq1kx8-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 08 Sep 2020 13:37:01 -0400 Received: from m0098404.ppops.net (m0098404.ppops.net [127.0.0.1]) by pps.reinject (8.16.0.36/8.16.0.36) with SMTP id 088HYuZt002693; Tue, 8 Sep 2020 13:36:58 -0400 Received: from ppma02fra.de.ibm.com (47.49.7a9f.ip4.static.sl-reverse.com [159.122.73.71]) by mx0a-001b2d01.pphosted.com with ESMTP id 33edqq1kvx-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 08 Sep 2020 13:36:58 -0400 Received: from pps.filterd (ppma02fra.de.ibm.com [127.0.0.1]) by ppma02fra.de.ibm.com (8.16.0.42/8.16.0.42) with SMTP id 088Hauxr003944; Tue, 8 Sep 2020 17:36:56 GMT Received: from b06cxnps4075.portsmouth.uk.ibm.com (d06relay12.portsmouth.uk.ibm.com [9.149.109.197]) by ppma02fra.de.ibm.com with ESMTP id 33c2a828a3-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 08 Sep 2020 17:36:55 +0000 Received: from d06av21.portsmouth.uk.ibm.com (d06av21.portsmouth.uk.ibm.com [9.149.105.232]) by b06cxnps4075.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 088Haql029163968 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 8 Sep 2020 17:36:52 GMT Received: from d06av21.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id B279352063; Tue, 8 Sep 2020 17:36:52 +0000 (GMT) Received: from thinkpad (unknown [9.171.25.197]) by d06av21.portsmouth.uk.ibm.com (Postfix) with SMTP id 89AD352050; Tue, 8 Sep 2020 17:36:51 +0000 (GMT) Date: Tue, 8 Sep 2020 19:36:50 +0200 From: Gerald Schaefer To: Christophe Leroy Cc: Mike Rapoport , Peter Zijlstra , 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 , Catalin Marinas , Andrey Ryabinin , Heiko Carstens , Arnd Bergmann , John Hubbard , Jeff Dike , linux-um , Borislav Petkov , Andy Lutomirski , Thomas Gleixner , linux-arm , linux-power , LKML , Andrew Morton , Linus Torvalds Subject: Re: [RFC PATCH v2 0/3] mm/gup: fix gup_fast with dynamic page table folding Message-ID: <20200908193650.1c1511d0@thinkpad> In-Reply-To: <9bde9857-fdfd-e384-ea27-a14e5a06f1e6@csgroup.eu> References: <20200907180058.64880-1-gerald.schaefer@linux.ibm.com> <20200907201256.GC1976319@kernel.org> <9bde9857-fdfd-e384-ea27-a14e5a06f1e6@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_09:2020-09-08,2020-09-08 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 lowpriorityscore=0 adultscore=0 bulkscore=0 malwarescore=0 phishscore=0 impostorscore=0 clxscore=1015 mlxscore=0 spamscore=0 priorityscore=1501 suspectscore=0 mlxlogscore=884 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2006250000 definitions=main-2009080165 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 8 Sep 2020 07:22:39 +0200 Christophe Leroy wrote: >=20 >=20 > Le 07/09/2020 =C3=A0 22:12, Mike Rapoport a =C3=A9crit=C2=A0: > > On Mon, Sep 07, 2020 at 08:00:55PM +0200, Gerald Schaefer wrote: > >> This is v2 of an RFC previously discussed here: > >> https://lore.kernel.org/lkml/20200828140314.8556-1-gerald.schaefer@lin= ux.ibm.com/ > >> > >> Patch 1 is a fix for a regression in gup_fast on s390, after our conve= rsion > >> to common gup_fast code. It will introduce special helper functions > >> pXd_addr_end_folded(), which have to be used in places where pagetable= walk > >> is done w/o lock and with READ_ONCE, so currently only in gup_fast. > >> > >> Patch 2 is an attempt to make that more generic, i.e. change pXd_addr_= end() > >> themselves by adding an extra pXd value parameter. That was suggested = by > >> Jason during v1 discussion, because he is already thinking of some oth= er > >> places where he might want to switch to the READ_ONCE logic for pageta= ble > >> walks. In general, that would be the cleanest / safest solution, but t= here > >> is some impact on other architectures and common code, hence the new a= nd > >> greatly enlarged recipient list. > >> > >> Patch 3 is a "nice to have" add-on, which makes pXd_addr_end() inline > >> functions instead of #defines, so that we get some type checking for t= he > >> new pXd value parameter. > >> > >> Not sure about Fixes/stable tags for the generic solution. Only patch 1 > >> fixes a real bug on s390, and has Fixes/stable tags. Patches 2 + 3 mig= ht > >> still be nice to have in stable, to ease future backports, but I guess > >> "nice to have" does not really qualify for stable backports. > >=20 > > I also think that adding pXd parameter to pXd_addr_end() is a cleaner > > way and with this patch 1 is not really required. I would even merge > > patches 2 and 3 into a single patch and use only it as the fix. >=20 > Why not merging patches 2 and 3, but I would keep patch 1 separate but=20 > after the generic changes, so that we first do the generic changes, then= =20 > we do the specific S390 use of it. Yes, we thought about that approach too. It would at least allow to get all into stable, more or less nicely, as prerequisite for the s390 fix. Two concerns kept us from going that way. For once, it might not be the nicest way to get it all in stable, and we would not want to risk further objections due to the imminent and rather scary data corruption issue that we want to fix asap. For the same reason, we thought that the generalization part might need more time and agreement from various people, so that we could at least get the first patch as short-term solution. It seems now that the generalization is very well accepted so far, apart from some apparent issues on arm. Also, merging 2 + 3 and putting them first seems to be acceptable, so we could do that for v3, if there are no objections. Of course, we first need to address the few remaining issues for arm(32?), which do look quite confusing to me so far. BTW, sorry for the compile error with patch 3, I guess we did the cross-compile only for 1 + 2 applied, to see the bloat-o-meter changes. But I guess patch 3 already proved its usefulness by that :-) From mboxrd@z Thu Jan 1 00:00:00 1970 From: Gerald Schaefer Date: Tue, 08 Sep 2020 17:36:50 +0000 Subject: Re: [RFC PATCH v2 0/3] mm/gup: fix gup_fast with dynamic page table folding Message-Id: <20200908193650.1c1511d0@thinkpad> List-Id: References: <20200907180058.64880-1-gerald.schaefer@linux.ibm.com> <20200907201256.GC1976319@kernel.org> <9bde9857-fdfd-e384-ea27-a14e5a06f1e6@csgroup.eu> In-Reply-To: <9bde9857-fdfd-e384-ea27-a14e5a06f1e6@csgroup.eu> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit To: Christophe Leroy Cc: Mike Rapoport , Peter Zijlstra , 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 , Catalin Marinas , Andrey Ryabinin , Heiko Carstens , Arnd Bergmann , John Hubbard , Jeff Dike , linux-um , Borislav Petkov , Andy Lutomirski , Thomas Gleixner , linux-arm , linux-power , LKML , Andrew Morton , Linus Torvalds On Tue, 8 Sep 2020 07:22:39 +0200 Christophe Leroy wrote: > > > Le 07/09/2020 à 22:12, Mike Rapoport a écrit : > > On Mon, Sep 07, 2020 at 08:00:55PM +0200, Gerald Schaefer wrote: > >> This is v2 of an RFC previously discussed here: > >> https://lore.kernel.org/lkml/20200828140314.8556-1-gerald.schaefer@linux.ibm.com/ > >> > >> Patch 1 is a fix for a regression in gup_fast on s390, after our conversion > >> to common gup_fast code. It will introduce special helper functions > >> pXd_addr_end_folded(), which have to be used in places where pagetable walk > >> is done w/o lock and with READ_ONCE, so currently only in gup_fast. > >> > >> Patch 2 is an attempt to make that more generic, i.e. change pXd_addr_end() > >> themselves by adding an extra pXd value parameter. That was suggested by > >> Jason during v1 discussion, because he is already thinking of some other > >> places where he might want to switch to the READ_ONCE logic for pagetable > >> walks. In general, that would be the cleanest / safest solution, but there > >> is some impact on other architectures and common code, hence the new and > >> greatly enlarged recipient list. > >> > >> Patch 3 is a "nice to have" add-on, which makes pXd_addr_end() inline > >> functions instead of #defines, so that we get some type checking for the > >> new pXd value parameter. > >> > >> Not sure about Fixes/stable tags for the generic solution. Only patch 1 > >> fixes a real bug on s390, and has Fixes/stable tags. Patches 2 + 3 might > >> still be nice to have in stable, to ease future backports, but I guess > >> "nice to have" does not really qualify for stable backports. > > > > I also think that adding pXd parameter to pXd_addr_end() is a cleaner > > way and with this patch 1 is not really required. I would even merge > > patches 2 and 3 into a single patch and use only it as the fix. > > Why not merging patches 2 and 3, but I would keep patch 1 separate but > after the generic changes, so that we first do the generic changes, then > we do the specific S390 use of it. Yes, we thought about that approach too. It would at least allow to get all into stable, more or less nicely, as prerequisite for the s390 fix. Two concerns kept us from going that way. For once, it might not be the nicest way to get it all in stable, and we would not want to risk further objections due to the imminent and rather scary data corruption issue that we want to fix asap. For the same reason, we thought that the generalization part might need more time and agreement from various people, so that we could at least get the first patch as short-term solution. It seems now that the generalization is very well accepted so far, apart from some apparent issues on arm. Also, merging 2 + 3 and putting them first seems to be acceptable, so we could do that for v3, if there are no objections. Of course, we first need to address the few remaining issues for arm(32?), which do look quite confusing to me so far. BTW, sorry for the compile error with patch 3, I guess we did the cross-compile only for 1 + 2 applied, to see the bloat-o-meter changes. But I guess patch 3 already proved its usefulness by that :-) 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 A3A0EC433E2 for ; Tue, 8 Sep 2020 17:40:10 +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 E92392078B for ; Tue, 8 Sep 2020 17:40:09 +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="CpOXYrIz" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org E92392078B 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 4BmC8k1CkwzDqH5 for ; Wed, 9 Sep 2020 03:40:06 +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=CpOXYrIz; 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 4BmC5s0SkXzDqGc for ; Wed, 9 Sep 2020 03:37:36 +1000 (AEST) Received: from pps.filterd (m0098404.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 088HX91w193873; Tue, 8 Sep 2020 13:37:02 -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=zTcPf30MWc1o3sVkuFOlszFjBszv6mbPeKxPdnXhSzU=; b=CpOXYrIzNqgah+XmLK3ao2p1ye9+BqkrW/W1vkBKNJnKCOWAruPC38o1UqN5H0fatOAw XumWZzfaC1TZGPFsow6W/myGfJbHhaD2OvuzQU0oxh2EDzoXjNHyJvsUt1Te4q4rOnxP hoH4fPXZ42JeutQXvPzj1LuseK96o+mcemAbZdpCDekWLg7A2PFNwMito9+ERwk99PLx nzqwnuOOTkECp7JT3Dm1gwXmzW5zTGO/Ua5IgYtQHrsvmvB5+rmFFLnzfuN/57SIWYYH vzeOQxBeZZr7qbY/CEExQHgWB8KAC0wqCkDbM8R27TiIV4YWSm2aGi/j8+grRA00NWav SA== Received: from pps.reinject (localhost [127.0.0.1]) by mx0a-001b2d01.pphosted.com with ESMTP id 33edqq1kx8-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 08 Sep 2020 13:37:01 -0400 Received: from m0098404.ppops.net (m0098404.ppops.net [127.0.0.1]) by pps.reinject (8.16.0.36/8.16.0.36) with SMTP id 088HYuZt002693; Tue, 8 Sep 2020 13:36:58 -0400 Received: from ppma02fra.de.ibm.com (47.49.7a9f.ip4.static.sl-reverse.com [159.122.73.71]) by mx0a-001b2d01.pphosted.com with ESMTP id 33edqq1kvx-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 08 Sep 2020 13:36:58 -0400 Received: from pps.filterd (ppma02fra.de.ibm.com [127.0.0.1]) by ppma02fra.de.ibm.com (8.16.0.42/8.16.0.42) with SMTP id 088Hauxr003944; Tue, 8 Sep 2020 17:36:56 GMT Received: from b06cxnps4075.portsmouth.uk.ibm.com (d06relay12.portsmouth.uk.ibm.com [9.149.109.197]) by ppma02fra.de.ibm.com with ESMTP id 33c2a828a3-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 08 Sep 2020 17:36:55 +0000 Received: from d06av21.portsmouth.uk.ibm.com (d06av21.portsmouth.uk.ibm.com [9.149.105.232]) by b06cxnps4075.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 088Haql029163968 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 8 Sep 2020 17:36:52 GMT Received: from d06av21.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id B279352063; Tue, 8 Sep 2020 17:36:52 +0000 (GMT) Received: from thinkpad (unknown [9.171.25.197]) by d06av21.portsmouth.uk.ibm.com (Postfix) with SMTP id 89AD352050; Tue, 8 Sep 2020 17:36:51 +0000 (GMT) Date: Tue, 8 Sep 2020 19:36:50 +0200 From: Gerald Schaefer To: Christophe Leroy Subject: Re: [RFC PATCH v2 0/3] mm/gup: fix gup_fast with dynamic page table folding Message-ID: <20200908193650.1c1511d0@thinkpad> In-Reply-To: <9bde9857-fdfd-e384-ea27-a14e5a06f1e6@csgroup.eu> References: <20200907180058.64880-1-gerald.schaefer@linux.ibm.com> <20200907201256.GC1976319@kernel.org> <9bde9857-fdfd-e384-ea27-a14e5a06f1e6@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_09:2020-09-08, 2020-09-08 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 lowpriorityscore=0 adultscore=0 bulkscore=0 malwarescore=0 phishscore=0 impostorscore=0 clxscore=1015 mlxscore=0 spamscore=0 priorityscore=1501 suspectscore=0 mlxlogscore=884 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2006250000 definitions=main-2009080165 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 , Jason Gunthorpe , Richard Weinberger , linux-x86 , Russell King , Christian Borntraeger , 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 07:22:39 +0200 Christophe Leroy wrote: >=20 >=20 > Le 07/09/2020 =C3=A0 22:12, Mike Rapoport a =C3=A9crit=C2=A0: > > On Mon, Sep 07, 2020 at 08:00:55PM +0200, Gerald Schaefer wrote: > >> This is v2 of an RFC previously discussed here: > >> https://lore.kernel.org/lkml/20200828140314.8556-1-gerald.schaefer@lin= ux.ibm.com/ > >> > >> Patch 1 is a fix for a regression in gup_fast on s390, after our conve= rsion > >> to common gup_fast code. It will introduce special helper functions > >> pXd_addr_end_folded(), which have to be used in places where pagetable= walk > >> is done w/o lock and with READ_ONCE, so currently only in gup_fast. > >> > >> Patch 2 is an attempt to make that more generic, i.e. change pXd_addr_= end() > >> themselves by adding an extra pXd value parameter. That was suggested = by > >> Jason during v1 discussion, because he is already thinking of some oth= er > >> places where he might want to switch to the READ_ONCE logic for pageta= ble > >> walks. In general, that would be the cleanest / safest solution, but t= here > >> is some impact on other architectures and common code, hence the new a= nd > >> greatly enlarged recipient list. > >> > >> Patch 3 is a "nice to have" add-on, which makes pXd_addr_end() inline > >> functions instead of #defines, so that we get some type checking for t= he > >> new pXd value parameter. > >> > >> Not sure about Fixes/stable tags for the generic solution. Only patch 1 > >> fixes a real bug on s390, and has Fixes/stable tags. Patches 2 + 3 mig= ht > >> still be nice to have in stable, to ease future backports, but I guess > >> "nice to have" does not really qualify for stable backports. > >=20 > > I also think that adding pXd parameter to pXd_addr_end() is a cleaner > > way and with this patch 1 is not really required. I would even merge > > patches 2 and 3 into a single patch and use only it as the fix. >=20 > Why not merging patches 2 and 3, but I would keep patch 1 separate but=20 > after the generic changes, so that we first do the generic changes, then= =20 > we do the specific S390 use of it. Yes, we thought about that approach too. It would at least allow to get all into stable, more or less nicely, as prerequisite for the s390 fix. Two concerns kept us from going that way. For once, it might not be the nicest way to get it all in stable, and we would not want to risk further objections due to the imminent and rather scary data corruption issue that we want to fix asap. For the same reason, we thought that the generalization part might need more time and agreement from various people, so that we could at least get the first patch as short-term solution. It seems now that the generalization is very well accepted so far, apart from some apparent issues on arm. Also, merging 2 + 3 and putting them first seems to be acceptable, so we could do that for v3, if there are no objections. Of course, we first need to address the few remaining issues for arm(32?), which do look quite confusing to me so far. BTW, sorry for the compile error with patch 3, I guess we did the cross-compile only for 1 + 2 applied, to see the bloat-o-meter changes. But I guess patch 3 already proved its usefulness by that :-) 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 13C0DC43461 for ; Tue, 8 Sep 2020 17:38:51 +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 A7A852078B for ; Tue, 8 Sep 2020 17:38:50 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="aXOOGnR+"; dkim=fail reason="signature verification failed" (2048-bit key) header.d=ibm.com header.i=@ibm.com header.b="CpOXYrIz" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org A7A852078B 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=Qfo/GkwJUDaMtE/Qm5Hv1V8O/ymjEpyOmM3kT7OUhtQ=; b=aXOOGnR+y4EfPx5IbUgt4gwaT T4Qi1oTCOT1Apn6p4SEba86ZeHSYIPR3fTo5rh+tqVTwxvH7vdWP5kDQnX3uNoFI32Z6figqq1Mks LPSv+OaKTMd4ohvt8u54nyKghe1hrcqNd4ATahfi9SLfcuOjz6jThF3yUykBBoTicF2RZ+ZY6A6W6 iF5sUeGv/47ragJeYv3Zi+yG25ZYxtM2uR+RDotFS3xAWSpHrJwZeZM+0jBhtyAsaDoPAAb7eSV3g BcpM3RcPGwVMlz/cwx5mb8KBpFyzuTYSnLZffV+1dIDF97AAr3cCoJZQrllg1hpawRukEiq9NBo8d 2J32xq1VA==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kFhYk-0006oa-P7; Tue, 08 Sep 2020 17:37:34 +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 1kFhYi-0006nn-Fu; Tue, 08 Sep 2020 17:37:33 +0000 Received: from pps.filterd (m0098404.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 088HX91w193873; Tue, 8 Sep 2020 13:37:02 -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=zTcPf30MWc1o3sVkuFOlszFjBszv6mbPeKxPdnXhSzU=; b=CpOXYrIzNqgah+XmLK3ao2p1ye9+BqkrW/W1vkBKNJnKCOWAruPC38o1UqN5H0fatOAw XumWZzfaC1TZGPFsow6W/myGfJbHhaD2OvuzQU0oxh2EDzoXjNHyJvsUt1Te4q4rOnxP hoH4fPXZ42JeutQXvPzj1LuseK96o+mcemAbZdpCDekWLg7A2PFNwMito9+ERwk99PLx nzqwnuOOTkECp7JT3Dm1gwXmzW5zTGO/Ua5IgYtQHrsvmvB5+rmFFLnzfuN/57SIWYYH vzeOQxBeZZr7qbY/CEExQHgWB8KAC0wqCkDbM8R27TiIV4YWSm2aGi/j8+grRA00NWav SA== Received: from pps.reinject (localhost [127.0.0.1]) by mx0a-001b2d01.pphosted.com with ESMTP id 33edqq1kx8-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 08 Sep 2020 13:37:01 -0400 Received: from m0098404.ppops.net (m0098404.ppops.net [127.0.0.1]) by pps.reinject (8.16.0.36/8.16.0.36) with SMTP id 088HYuZt002693; Tue, 8 Sep 2020 13:36:58 -0400 Received: from ppma02fra.de.ibm.com (47.49.7a9f.ip4.static.sl-reverse.com [159.122.73.71]) by mx0a-001b2d01.pphosted.com with ESMTP id 33edqq1kvx-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 08 Sep 2020 13:36:58 -0400 Received: from pps.filterd (ppma02fra.de.ibm.com [127.0.0.1]) by ppma02fra.de.ibm.com (8.16.0.42/8.16.0.42) with SMTP id 088Hauxr003944; Tue, 8 Sep 2020 17:36:56 GMT Received: from b06cxnps4075.portsmouth.uk.ibm.com (d06relay12.portsmouth.uk.ibm.com [9.149.109.197]) by ppma02fra.de.ibm.com with ESMTP id 33c2a828a3-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 08 Sep 2020 17:36:55 +0000 Received: from d06av21.portsmouth.uk.ibm.com (d06av21.portsmouth.uk.ibm.com [9.149.105.232]) by b06cxnps4075.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 088Haql029163968 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 8 Sep 2020 17:36:52 GMT Received: from d06av21.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id B279352063; Tue, 8 Sep 2020 17:36:52 +0000 (GMT) Received: from thinkpad (unknown [9.171.25.197]) by d06av21.portsmouth.uk.ibm.com (Postfix) with SMTP id 89AD352050; Tue, 8 Sep 2020 17:36:51 +0000 (GMT) Date: Tue, 8 Sep 2020 19:36:50 +0200 From: Gerald Schaefer To: Christophe Leroy Subject: Re: [RFC PATCH v2 0/3] mm/gup: fix gup_fast with dynamic page table folding Message-ID: <20200908193650.1c1511d0@thinkpad> In-Reply-To: <9bde9857-fdfd-e384-ea27-a14e5a06f1e6@csgroup.eu> References: <20200907180058.64880-1-gerald.schaefer@linux.ibm.com> <20200907201256.GC1976319@kernel.org> <9bde9857-fdfd-e384-ea27-a14e5a06f1e6@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_09:2020-09-08, 2020-09-08 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 lowpriorityscore=0 adultscore=0 bulkscore=0 malwarescore=0 phishscore=0 impostorscore=0 clxscore=1015 mlxscore=0 spamscore=0 priorityscore=1501 suspectscore=0 mlxlogscore=884 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2006250000 definitions=main-2009080165 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200908_133732_696223_C1909BD2 X-CRM114-Status: GOOD ( 40.80 ) 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 , Jason Gunthorpe , Richard Weinberger , linux-x86 , Russell King , Christian Borntraeger , 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 T24gVHVlLCA4IFNlcCAyMDIwIDA3OjIyOjM5ICswMjAwCkNocmlzdG9waGUgTGVyb3kgPGNocmlz dG9waGUubGVyb3lAY3Nncm91cC5ldT4gd3JvdGU6Cgo+IAo+IAo+IExlIDA3LzA5LzIwMjAgw6Ag MjI6MTIsIE1pa2UgUmFwb3BvcnQgYSDDqWNyaXTCoDoKPiA+IE9uIE1vbiwgU2VwIDA3LCAyMDIw IGF0IDA4OjAwOjU1UE0gKzAyMDAsIEdlcmFsZCBTY2hhZWZlciB3cm90ZToKPiA+PiBUaGlzIGlz IHYyIG9mIGFuIFJGQyBwcmV2aW91c2x5IGRpc2N1c3NlZCBoZXJlOgo+ID4+IGh0dHBzOi8vbG9y ZS5rZXJuZWwub3JnL2xrbWwvMjAyMDA4MjgxNDAzMTQuODU1Ni0xLWdlcmFsZC5zY2hhZWZlckBs aW51eC5pYm0uY29tLwo+ID4+Cj4gPj4gUGF0Y2ggMSBpcyBhIGZpeCBmb3IgYSByZWdyZXNzaW9u IGluIGd1cF9mYXN0IG9uIHMzOTAsIGFmdGVyIG91ciBjb252ZXJzaW9uCj4gPj4gdG8gY29tbW9u IGd1cF9mYXN0IGNvZGUuIEl0IHdpbGwgaW50cm9kdWNlIHNwZWNpYWwgaGVscGVyIGZ1bmN0aW9u cwo+ID4+IHBYZF9hZGRyX2VuZF9mb2xkZWQoKSwgd2hpY2ggaGF2ZSB0byBiZSB1c2VkIGluIHBs YWNlcyB3aGVyZSBwYWdldGFibGUgd2Fsawo+ID4+IGlzIGRvbmUgdy9vIGxvY2sgYW5kIHdpdGgg UkVBRF9PTkNFLCBzbyBjdXJyZW50bHkgb25seSBpbiBndXBfZmFzdC4KPiA+Pgo+ID4+IFBhdGNo IDIgaXMgYW4gYXR0ZW1wdCB0byBtYWtlIHRoYXQgbW9yZSBnZW5lcmljLCBpLmUuIGNoYW5nZSBw WGRfYWRkcl9lbmQoKQo+ID4+IHRoZW1zZWx2ZXMgYnkgYWRkaW5nIGFuIGV4dHJhIHBYZCB2YWx1 ZSBwYXJhbWV0ZXIuIFRoYXQgd2FzIHN1Z2dlc3RlZCBieQo+ID4+IEphc29uIGR1cmluZyB2MSBk aXNjdXNzaW9uLCBiZWNhdXNlIGhlIGlzIGFscmVhZHkgdGhpbmtpbmcgb2Ygc29tZSBvdGhlcgo+ ID4+IHBsYWNlcyB3aGVyZSBoZSBtaWdodCB3YW50IHRvIHN3aXRjaCB0byB0aGUgUkVBRF9PTkNF IGxvZ2ljIGZvciBwYWdldGFibGUKPiA+PiB3YWxrcy4gSW4gZ2VuZXJhbCwgdGhhdCB3b3VsZCBi ZSB0aGUgY2xlYW5lc3QgLyBzYWZlc3Qgc29sdXRpb24sIGJ1dCB0aGVyZQo+ID4+IGlzIHNvbWUg aW1wYWN0IG9uIG90aGVyIGFyY2hpdGVjdHVyZXMgYW5kIGNvbW1vbiBjb2RlLCBoZW5jZSB0aGUg bmV3IGFuZAo+ID4+IGdyZWF0bHkgZW5sYXJnZWQgcmVjaXBpZW50IGxpc3QuCj4gPj4KPiA+PiBQ YXRjaCAzIGlzIGEgIm5pY2UgdG8gaGF2ZSIgYWRkLW9uLCB3aGljaCBtYWtlcyBwWGRfYWRkcl9l bmQoKSBpbmxpbmUKPiA+PiBmdW5jdGlvbnMgaW5zdGVhZCBvZiAjZGVmaW5lcywgc28gdGhhdCB3 ZSBnZXQgc29tZSB0eXBlIGNoZWNraW5nIGZvciB0aGUKPiA+PiBuZXcgcFhkIHZhbHVlIHBhcmFt ZXRlci4KPiA+Pgo+ID4+IE5vdCBzdXJlIGFib3V0IEZpeGVzL3N0YWJsZSB0YWdzIGZvciB0aGUg Z2VuZXJpYyBzb2x1dGlvbi4gT25seSBwYXRjaCAxCj4gPj4gZml4ZXMgYSByZWFsIGJ1ZyBvbiBz MzkwLCBhbmQgaGFzIEZpeGVzL3N0YWJsZSB0YWdzLiBQYXRjaGVzIDIgKyAzIG1pZ2h0Cj4gPj4g c3RpbGwgYmUgbmljZSB0byBoYXZlIGluIHN0YWJsZSwgdG8gZWFzZSBmdXR1cmUgYmFja3BvcnRz LCBidXQgSSBndWVzcwo+ID4+ICJuaWNlIHRvIGhhdmUiIGRvZXMgbm90IHJlYWxseSBxdWFsaWZ5 IGZvciBzdGFibGUgYmFja3BvcnRzLgo+ID4gCj4gPiBJIGFsc28gdGhpbmsgdGhhdCBhZGRpbmcg cFhkIHBhcmFtZXRlciB0byBwWGRfYWRkcl9lbmQoKSBpcyBhIGNsZWFuZXIKPiA+IHdheSBhbmQg d2l0aCB0aGlzIHBhdGNoIDEgaXMgbm90IHJlYWxseSByZXF1aXJlZC4gSSB3b3VsZCBldmVuIG1l cmdlCj4gPiBwYXRjaGVzIDIgYW5kIDMgaW50byBhIHNpbmdsZSBwYXRjaCBhbmQgdXNlIG9ubHkg aXQgYXMgdGhlIGZpeC4KPiAKPiBXaHkgbm90IG1lcmdpbmcgcGF0Y2hlcyAyIGFuZCAzLCBidXQg SSB3b3VsZCBrZWVwIHBhdGNoIDEgc2VwYXJhdGUgYnV0IAo+IGFmdGVyIHRoZSBnZW5lcmljIGNo YW5nZXMsIHNvIHRoYXQgd2UgZmlyc3QgZG8gdGhlIGdlbmVyaWMgY2hhbmdlcywgdGhlbiAKPiB3 ZSBkbyB0aGUgc3BlY2lmaWMgUzM5MCB1c2Ugb2YgaXQuCgpZZXMsIHdlIHRob3VnaHQgYWJvdXQg dGhhdCBhcHByb2FjaCB0b28uIEl0IHdvdWxkIGF0IGxlYXN0IGFsbG93IHRvCmdldCBhbGwgaW50 byBzdGFibGUsIG1vcmUgb3IgbGVzcyBuaWNlbHksIGFzIHByZXJlcXVpc2l0ZSBmb3IgdGhlIHMz OTAKZml4LgoKVHdvIGNvbmNlcm5zIGtlcHQgdXMgZnJvbSBnb2luZyB0aGF0IHdheS4gRm9yIG9u Y2UsIGl0IG1pZ2h0IG5vdCBiZQp0aGUgbmljZXN0IHdheSB0byBnZXQgaXQgYWxsIGluIHN0YWJs ZSwgYW5kIHdlIHdvdWxkIG5vdCB3YW50IHRvIHJpc2sKZnVydGhlciBvYmplY3Rpb25zIGR1ZSB0 byB0aGUgaW1taW5lbnQgYW5kIHJhdGhlciBzY2FyeSBkYXRhIGNvcnJ1cHRpb24KaXNzdWUgdGhh dCB3ZSB3YW50IHRvIGZpeCBhc2FwLgoKRm9yIHRoZSBzYW1lIHJlYXNvbiwgd2UgdGhvdWdodCB0 aGF0IHRoZSBnZW5lcmFsaXphdGlvbiBwYXJ0IG1pZ2h0Cm5lZWQgbW9yZSB0aW1lIGFuZCBhZ3Jl ZW1lbnQgZnJvbSB2YXJpb3VzIHBlb3BsZSwgc28gdGhhdCB3ZSBjb3VsZCBhdApsZWFzdCBnZXQg dGhlIGZpcnN0IHBhdGNoIGFzIHNob3J0LXRlcm0gc29sdXRpb24uCgpJdCBzZWVtcyBub3cgdGhh dCB0aGUgZ2VuZXJhbGl6YXRpb24gaXMgdmVyeSB3ZWxsIGFjY2VwdGVkIHNvIGZhciwKYXBhcnQg ZnJvbSBzb21lIGFwcGFyZW50IGlzc3VlcyBvbiBhcm0uIEFsc28sIG1lcmdpbmcgMiArIDMgYW5k CnB1dHRpbmcgdGhlbSBmaXJzdCBzZWVtcyB0byBiZSBhY2NlcHRhYmxlLCBzbyB3ZSBjb3VsZCBk byB0aGF0IGZvcgp2MywgaWYgdGhlcmUgYXJlIG5vIG9iamVjdGlvbnMuCgpPZiBjb3Vyc2UsIHdl IGZpcnN0IG5lZWQgdG8gYWRkcmVzcyB0aGUgZmV3IHJlbWFpbmluZyBpc3N1ZXMgZm9yCmFybSgz Mj8pLCB3aGljaCBkbyBsb29rIHF1aXRlIGNvbmZ1c2luZyB0byBtZSBzbyBmYXIuIEJUVywgc29y cnkgZm9yCnRoZSBjb21waWxlIGVycm9yIHdpdGggcGF0Y2ggMywgSSBndWVzcyB3ZSBkaWQgdGhl IGNyb3NzLWNvbXBpbGUgb25seQpmb3IgMSArIDIgYXBwbGllZCwgdG8gc2VlIHRoZSBibG9hdC1v LW1ldGVyIGNoYW5nZXMuIEJ1dCBJIGd1ZXNzCnBhdGNoIDMgYWxyZWFkeSBwcm92ZWQgaXRzIHVz ZWZ1bG5lc3MgYnkgdGhhdCA6LSkKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fCmxpbnV4LWFybS1rZXJuZWwgbWFpbGluZyBsaXN0CmxpbnV4LWFybS1rZXJu ZWxAbGlzdHMuaW5mcmFkZWFkLm9yZwpodHRwOi8vbGlzdHMuaW5mcmFkZWFkLm9yZy9tYWlsbWFu L2xpc3RpbmZvL2xpbnV4LWFybS1rZXJuZWwK From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Tue, 8 Sep 2020 19:36:50 +0200 From: Gerald Schaefer Subject: Re: [RFC PATCH v2 0/3] mm/gup: fix gup_fast with dynamic page table folding Message-ID: <20200908193650.1c1511d0@thinkpad> In-Reply-To: <9bde9857-fdfd-e384-ea27-a14e5a06f1e6@csgroup.eu> References: <20200907180058.64880-1-gerald.schaefer@linux.ibm.com> <20200907201256.GC1976319@kernel.org> <9bde9857-fdfd-e384-ea27-a14e5a06f1e6@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 , Jason Gunthorpe , Richard Weinberger , linux-x86 , Russell King , Christian Borntraeger , 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 T24gVHVlLCA4IFNlcCAyMDIwIDA3OjIyOjM5ICswMjAwCkNocmlzdG9waGUgTGVyb3kgPGNocmlz dG9waGUubGVyb3lAY3Nncm91cC5ldT4gd3JvdGU6Cgo+IAo+IAo+IExlIDA3LzA5LzIwMjAgw6Ag MjI6MTIsIE1pa2UgUmFwb3BvcnQgYSDDqWNyaXTCoDoKPiA+IE9uIE1vbiwgU2VwIDA3LCAyMDIw IGF0IDA4OjAwOjU1UE0gKzAyMDAsIEdlcmFsZCBTY2hhZWZlciB3cm90ZToKPiA+PiBUaGlzIGlz IHYyIG9mIGFuIFJGQyBwcmV2aW91c2x5IGRpc2N1c3NlZCBoZXJlOgo+ID4+IGh0dHBzOi8vbG9y ZS5rZXJuZWwub3JnL2xrbWwvMjAyMDA4MjgxNDAzMTQuODU1Ni0xLWdlcmFsZC5zY2hhZWZlckBs aW51eC5pYm0uY29tLwo+ID4+Cj4gPj4gUGF0Y2ggMSBpcyBhIGZpeCBmb3IgYSByZWdyZXNzaW9u IGluIGd1cF9mYXN0IG9uIHMzOTAsIGFmdGVyIG91ciBjb252ZXJzaW9uCj4gPj4gdG8gY29tbW9u IGd1cF9mYXN0IGNvZGUuIEl0IHdpbGwgaW50cm9kdWNlIHNwZWNpYWwgaGVscGVyIGZ1bmN0aW9u cwo+ID4+IHBYZF9hZGRyX2VuZF9mb2xkZWQoKSwgd2hpY2ggaGF2ZSB0byBiZSB1c2VkIGluIHBs YWNlcyB3aGVyZSBwYWdldGFibGUgd2Fsawo+ID4+IGlzIGRvbmUgdy9vIGxvY2sgYW5kIHdpdGgg UkVBRF9PTkNFLCBzbyBjdXJyZW50bHkgb25seSBpbiBndXBfZmFzdC4KPiA+Pgo+ID4+IFBhdGNo IDIgaXMgYW4gYXR0ZW1wdCB0byBtYWtlIHRoYXQgbW9yZSBnZW5lcmljLCBpLmUuIGNoYW5nZSBw WGRfYWRkcl9lbmQoKQo+ID4+IHRoZW1zZWx2ZXMgYnkgYWRkaW5nIGFuIGV4dHJhIHBYZCB2YWx1 ZSBwYXJhbWV0ZXIuIFRoYXQgd2FzIHN1Z2dlc3RlZCBieQo+ID4+IEphc29uIGR1cmluZyB2MSBk aXNjdXNzaW9uLCBiZWNhdXNlIGhlIGlzIGFscmVhZHkgdGhpbmtpbmcgb2Ygc29tZSBvdGhlcgo+ ID4+IHBsYWNlcyB3aGVyZSBoZSBtaWdodCB3YW50IHRvIHN3aXRjaCB0byB0aGUgUkVBRF9PTkNF IGxvZ2ljIGZvciBwYWdldGFibGUKPiA+PiB3YWxrcy4gSW4gZ2VuZXJhbCwgdGhhdCB3b3VsZCBi ZSB0aGUgY2xlYW5lc3QgLyBzYWZlc3Qgc29sdXRpb24sIGJ1dCB0aGVyZQo+ID4+IGlzIHNvbWUg aW1wYWN0IG9uIG90aGVyIGFyY2hpdGVjdHVyZXMgYW5kIGNvbW1vbiBjb2RlLCBoZW5jZSB0aGUg bmV3IGFuZAo+ID4+IGdyZWF0bHkgZW5sYXJnZWQgcmVjaXBpZW50IGxpc3QuCj4gPj4KPiA+PiBQ YXRjaCAzIGlzIGEgIm5pY2UgdG8gaGF2ZSIgYWRkLW9uLCB3aGljaCBtYWtlcyBwWGRfYWRkcl9l bmQoKSBpbmxpbmUKPiA+PiBmdW5jdGlvbnMgaW5zdGVhZCBvZiAjZGVmaW5lcywgc28gdGhhdCB3 ZSBnZXQgc29tZSB0eXBlIGNoZWNraW5nIGZvciB0aGUKPiA+PiBuZXcgcFhkIHZhbHVlIHBhcmFt ZXRlci4KPiA+Pgo+ID4+IE5vdCBzdXJlIGFib3V0IEZpeGVzL3N0YWJsZSB0YWdzIGZvciB0aGUg Z2VuZXJpYyBzb2x1dGlvbi4gT25seSBwYXRjaCAxCj4gPj4gZml4ZXMgYSByZWFsIGJ1ZyBvbiBz MzkwLCBhbmQgaGFzIEZpeGVzL3N0YWJsZSB0YWdzLiBQYXRjaGVzIDIgKyAzIG1pZ2h0Cj4gPj4g c3RpbGwgYmUgbmljZSB0byBoYXZlIGluIHN0YWJsZSwgdG8gZWFzZSBmdXR1cmUgYmFja3BvcnRz LCBidXQgSSBndWVzcwo+ID4+ICJuaWNlIHRvIGhhdmUiIGRvZXMgbm90IHJlYWxseSBxdWFsaWZ5 IGZvciBzdGFibGUgYmFja3BvcnRzLgo+ID4gCj4gPiBJIGFsc28gdGhpbmsgdGhhdCBhZGRpbmcg cFhkIHBhcmFtZXRlciB0byBwWGRfYWRkcl9lbmQoKSBpcyBhIGNsZWFuZXIKPiA+IHdheSBhbmQg d2l0aCB0aGlzIHBhdGNoIDEgaXMgbm90IHJlYWxseSByZXF1aXJlZC4gSSB3b3VsZCBldmVuIG1l cmdlCj4gPiBwYXRjaGVzIDIgYW5kIDMgaW50byBhIHNpbmdsZSBwYXRjaCBhbmQgdXNlIG9ubHkg aXQgYXMgdGhlIGZpeC4KPiAKPiBXaHkgbm90IG1lcmdpbmcgcGF0Y2hlcyAyIGFuZCAzLCBidXQg SSB3b3VsZCBrZWVwIHBhdGNoIDEgc2VwYXJhdGUgYnV0IAo+IGFmdGVyIHRoZSBnZW5lcmljIGNo YW5nZXMsIHNvIHRoYXQgd2UgZmlyc3QgZG8gdGhlIGdlbmVyaWMgY2hhbmdlcywgdGhlbiAKPiB3 ZSBkbyB0aGUgc3BlY2lmaWMgUzM5MCB1c2Ugb2YgaXQuCgpZZXMsIHdlIHRob3VnaHQgYWJvdXQg dGhhdCBhcHByb2FjaCB0b28uIEl0IHdvdWxkIGF0IGxlYXN0IGFsbG93IHRvCmdldCBhbGwgaW50 byBzdGFibGUsIG1vcmUgb3IgbGVzcyBuaWNlbHksIGFzIHByZXJlcXVpc2l0ZSBmb3IgdGhlIHMz OTAKZml4LgoKVHdvIGNvbmNlcm5zIGtlcHQgdXMgZnJvbSBnb2luZyB0aGF0IHdheS4gRm9yIG9u Y2UsIGl0IG1pZ2h0IG5vdCBiZQp0aGUgbmljZXN0IHdheSB0byBnZXQgaXQgYWxsIGluIHN0YWJs ZSwgYW5kIHdlIHdvdWxkIG5vdCB3YW50IHRvIHJpc2sKZnVydGhlciBvYmplY3Rpb25zIGR1ZSB0 byB0aGUgaW1taW5lbnQgYW5kIHJhdGhlciBzY2FyeSBkYXRhIGNvcnJ1cHRpb24KaXNzdWUgdGhh dCB3ZSB3YW50IHRvIGZpeCBhc2FwLgoKRm9yIHRoZSBzYW1lIHJlYXNvbiwgd2UgdGhvdWdodCB0 aGF0IHRoZSBnZW5lcmFsaXphdGlvbiBwYXJ0IG1pZ2h0Cm5lZWQgbW9yZSB0aW1lIGFuZCBhZ3Jl ZW1lbnQgZnJvbSB2YXJpb3VzIHBlb3BsZSwgc28gdGhhdCB3ZSBjb3VsZCBhdApsZWFzdCBnZXQg dGhlIGZpcnN0IHBhdGNoIGFzIHNob3J0LXRlcm0gc29sdXRpb24uCgpJdCBzZWVtcyBub3cgdGhh dCB0aGUgZ2VuZXJhbGl6YXRpb24gaXMgdmVyeSB3ZWxsIGFjY2VwdGVkIHNvIGZhciwKYXBhcnQg ZnJvbSBzb21lIGFwcGFyZW50IGlzc3VlcyBvbiBhcm0uIEFsc28sIG1lcmdpbmcgMiArIDMgYW5k CnB1dHRpbmcgdGhlbSBmaXJzdCBzZWVtcyB0byBiZSBhY2NlcHRhYmxlLCBzbyB3ZSBjb3VsZCBk byB0aGF0IGZvcgp2MywgaWYgdGhlcmUgYXJlIG5vIG9iamVjdGlvbnMuCgpPZiBjb3Vyc2UsIHdl IGZpcnN0IG5lZWQgdG8gYWRkcmVzcyB0aGUgZmV3IHJlbWFpbmluZyBpc3N1ZXMgZm9yCmFybSgz Mj8pLCB3aGljaCBkbyBsb29rIHF1aXRlIGNvbmZ1c2luZyB0byBtZSBzbyBmYXIuIEJUVywgc29y cnkgZm9yCnRoZSBjb21waWxlIGVycm9yIHdpdGggcGF0Y2ggMywgSSBndWVzcyB3ZSBkaWQgdGhl IGNyb3NzLWNvbXBpbGUgb25seQpmb3IgMSArIDIgYXBwbGllZCwgdG8gc2VlIHRoZSBibG9hdC1v LW1ldGVyIGNoYW5nZXMuIEJ1dCBJIGd1ZXNzCnBhdGNoIDMgYWxyZWFkeSBwcm92ZWQgaXRzIHVz ZWZ1bG5lc3MgYnkgdGhhdCA6LSkKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fCmxpbnV4LXVtIG1haWxpbmcgbGlzdApsaW51eC11bUBsaXN0cy5pbmZyYWRl YWQub3JnCmh0dHA6Ly9saXN0cy5pbmZyYWRlYWQub3JnL21haWxtYW4vbGlzdGluZm8vbGludXgt dW0K