From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qk1-x744.google.com ([2607:f8b0:4864:20::744]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1kGODY-0000NY-Aq for linux-um@lists.infradead.org; Thu, 10 Sep 2020 15:10:33 +0000 Received: by mail-qk1-x744.google.com with SMTP id o16so6365424qkj.10 for ; Thu, 10 Sep 2020 08:10:30 -0700 (PDT) Date: Thu, 10 Sep 2020 12:10:26 -0300 From: Jason Gunthorpe Subject: Re: [RFC PATCH v2 1/3] mm/gup: fix gup_fast with dynamic page table folding Message-ID: <20200910151026.GL87483@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> <20200910152803.1a930afc@thinkpad> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20200910152803.1a930afc@thinkpad> 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: Gerald Schaefer , Anshuman Khandual Cc: Peter Zijlstra , Benjamin Herrenschmidt , Dave Hansen , Dave Hansen , Paul Mackerras , linux-sparc , Alexander Gordeev , Claudio Imbrenda , Will Deacon , linux-arch , linux-s390 , Vasily Gorbik , Richard Weinberger , linux-x86 , Russell King , Christian Borntraeger , 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-mm , linux-power , LKML , Michael Ellerman , Andrew Morton , Linus Torvalds , Mike Rapoport On Thu, Sep 10, 2020 at 03:28:03PM +0200, Gerald Schaefer wrote: > 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. No, I disagree. The page walker API the arch presents has to have well defined semantics. For instance, there is an effort to define tests and invarients for the page table accesses to bring this understanding and uniformity: mm/debug_vm_pgtable.c If we fix S390 using the pX_addr_end() change then the above should be updated with an invariant to check it. I've added Anshuman for some thoughts.. For better or worse, that invariant does exclude arches from using other folding techniques. The other solution would be to address the other side of != and adjust the pud++ eg replcae pud++ with something like: pud = pud_next_entry(p4d, pud, next) Such that: pud_next_entry(p4d, pud, next) === pud_offset(p4d, next) In which case the invarient changes to 'callers can never do pointer arithmetic on the result of pXX_offset()' which is a bit harder to enforce. Jason _______________________________________________ linux-um mailing list linux-um@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-um