From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qk1-x741.google.com ([2607:f8b0:4864:20::741]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1kGMDl-0001Cw-H4 for linux-um@lists.infradead.org; Thu, 10 Sep 2020 13:02:39 +0000 Received: by mail-qk1-x741.google.com with SMTP id n133so5857920qkn.11 for ; Thu, 10 Sep 2020 06:02:36 -0700 (PDT) Date: Thu, 10 Sep 2020 10:02:33 -0300 From: Jason Gunthorpe Subject: Re: [RFC PATCH v2 1/3] mm/gup: fix gup_fast with dynamic page table folding Message-ID: <20200910130233.GK87483@ziepe.ca> References: <20200907180058.64880-1-gerald.schaefer@linux.ibm.com> <20200907180058.64880-2-gerald.schaefer@linux.ibm.com> <0dbc6ec8-45ea-0853-4856-2bc1e661a5a5@intel.com> <20200909142904.00b72921@thinkpad> <20200909192534.442f8984@thinkpad> <20200909180324.GI87483@ziepe.ca> <20200910093925.GB29166@oc3871087118.ibm.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20200910093925.GB29166@oc3871087118.ibm.com> List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-um" Errors-To: linux-um-bounces+geert=linux-m68k.org@lists.infradead.org To: Alexander Gordeev Cc: Peter Zijlstra , Benjamin Herrenschmidt , Dave Hansen , Dave Hansen , Paul Mackerras , linux-sparc , Claudio Imbrenda , Will Deacon , linux-arch , linux-s390 , Vasily Gorbik , Richard Weinberger , linux-x86 , Russell King , Christian Borntraeger , Ingo Molnar , Catalin Marinas , Andrey Ryabinin , Gerald Schaefer , Heiko Carstens , Arnd Bergmann , John Hubbard , Jeff Dike , linux-um , Borislav Petkov , Andy Lutomirski , Thomas Gleixner , linux-arm , linux-mm , linux-power , LKML , Michael Ellerman , Andrew Morton , Linus Torvalds , Mike Rapoport On Thu, Sep 10, 2020 at 11:39:25AM +0200, Alexander Gordeev wrote: > As Gerald mentioned, it is very difficult to explain in a clear way. > Hopefully, one could make sense ot of it. I would say the page table API requires this invariant: pud = pud_offset(p4d, addr); do { WARN_ON(pud != pud_offset(p4d, addr); next = pud_addr_end(addr, end); } while (pud++, addr = next, addr != end); ie pud++ is supposed to be a shortcut for pud_offset(p4d, next) While S390 does not follow this. Fixing addr_end brings it into alignment by preventing pud++ from happening. The only currently known side effect is that gup_fast crashes, but it sure is an unexpected thing. This suggests another fix, which is to say that pud++ is undefined and pud_offset() must always be called, but I think that would cause worse codegen on all other archs. Jason _______________________________________________ linux-um mailing list linux-um@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-um