From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx0a-001b2d01.pphosted.com ([148.163.156.1]:47814 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730889AbgIJN2u (ORCPT ); Thu, 10 Sep 2020 09:28:50 -0400 Date: Thu, 10 Sep 2020 15:28:03 +0200 From: Gerald Schaefer Subject: Re: [RFC PATCH v2 1/3] mm/gup: fix gup_fast with dynamic page table folding Message-ID: <20200910152803.1a930afc@thinkpad> In-Reply-To: <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> <20200910130233.GK87483@ziepe.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-s390-owner@vger.kernel.org List-ID: To: Jason Gunthorpe Cc: Alexander Gordeev , Dave Hansen , John Hubbard , LKML , linux-mm , linux-arch , Andrew Morton , Linus Torvalds , Russell King , Mike Rapoport , Catalin Marinas , Will Deacon , Michael Ellerman , Benjamin Herrenschmidt , Paul Mackerras , Jeff Dike , Richard Weinberger , Dave Hansen , Andy Lutomirski , Peter Zijlstra , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Arnd Bergmann , Andrey Ryabinin , linux-x86 , linux-arm , linux-power , linux-sparc , linux-um , linux-s390 , Vasily Gorbik , Heiko Carstens , Christian Borntraeger , Claudio Imbrenda On Thu, 10 Sep 2020 10:02:33 -0300 Jason Gunthorpe wrote: > 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. It only is unexpected in a "top-level folding" world, see my other reply. Consider it an optimization, which was possible because of how our dynamic folding works, and e.g. because we can determine the correct pagetable level from a pXd value in pXd_offset. > 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. There really is nothing to fix for s390 outside of gup_fast, or other potential future READ_ONCE pagetable walkers. We do take the side-effect of the generic change on all other pagetable walkers for s390, but it really is rather a slight degradation than a fix.