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=-6.9 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE, SPF_PASS,USER_AGENT_SANE_1 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 F1C8CC433E2 for ; Tue, 8 Sep 2020 12:40:26 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id F01E822206 for ; Tue, 8 Sep 2020 12:40:25 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org F01E822206 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=csgroup.eu Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 4A9E58E0001; Tue, 8 Sep 2020 08:40:25 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 47E016B005D; Tue, 8 Sep 2020 08:40:25 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 395178E0001; Tue, 8 Sep 2020 08:40:25 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0022.hostedemail.com [216.40.44.22]) by kanga.kvack.org (Postfix) with ESMTP id 232696B005C for ; Tue, 8 Sep 2020 08:40:25 -0400 (EDT) Received: from smtpin18.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id D5E69181AC9CB for ; Tue, 8 Sep 2020 12:40:24 +0000 (UTC) X-FDA: 77239852368.18.crook71_4304b30270d4 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin18.hostedemail.com (Postfix) with ESMTP id 9559D100EC662 for ; Tue, 8 Sep 2020 12:40:24 +0000 (UTC) X-HE-Tag: crook71_4304b30270d4 X-Filterd-Recvd-Size: 6030 Received: from pegase1.c-s.fr (pegase1.c-s.fr [93.17.236.30]) by imf50.hostedemail.com (Postfix) with ESMTP for ; Tue, 8 Sep 2020 12:40:23 +0000 (UTC) Received: from localhost (mailhub1-int [192.168.12.234]) by localhost (Postfix) with ESMTP id 4Bm4Vr1mvXz9tysg; Tue, 8 Sep 2020 14:40:20 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at c-s.fr Received: from pegase1.c-s.fr ([192.168.12.234]) by localhost (pegase1.c-s.fr [192.168.12.234]) (amavisd-new, port 10024) with ESMTP id cIMhaNVcmlrN; Tue, 8 Sep 2020 14:40:20 +0200 (CEST) Received: from messagerie.si.c-s.fr (messagerie.si.c-s.fr [192.168.25.192]) by pegase1.c-s.fr (Postfix) with ESMTP id 4Bm4Vr0fBLz9tysZ; Tue, 8 Sep 2020 14:40:20 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by messagerie.si.c-s.fr (Postfix) with ESMTP id 5BBAE8B7C1; Tue, 8 Sep 2020 14:40:21 +0200 (CEST) X-Virus-Scanned: amavisd-new at c-s.fr Received: from messagerie.si.c-s.fr ([127.0.0.1]) by localhost (messagerie.si.c-s.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id xwRqAZ7QC05H; Tue, 8 Sep 2020 14:40:21 +0200 (CEST) Received: from [192.168.4.90] (unknown [192.168.4.90]) by messagerie.si.c-s.fr (Postfix) with ESMTP id B7AA88B7BE; Tue, 8 Sep 2020 14:40:18 +0200 (CEST) Subject: Re: [RFC PATCH v2 1/3] mm/gup: fix gup_fast with dynamic page table folding To: Christian Borntraeger , Gerald Schaefer , Jason Gunthorpe , John Hubbard Cc: 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 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> From: Christophe Leroy Message-ID: <96b80926-cf5b-1afa-9b7a-949a2188e61f@csgroup.eu> Date: Tue, 8 Sep 2020 14:40:10 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: <70a3dcb5-5ed1-6efa-6158-d0573d6927da@de.ibm.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr X-Rspamd-Queue-Id: 9559D100EC662 X-Spamd-Result: default: False [0.00 / 100.00] X-Rspamd-Server: rspam04 Content-Transfer-Encoding: quoted-printable X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: 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 a= n >>> 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= _end_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? 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. Regardless, I was wondering, why do we need a reference to the pXd at=20 all when calling pXd_addr_end() ? Couldn't S390 retrieve the pXd by using the pXd_offset() dance with the=20 passed addr ? Christophe