From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qv1-xf41.google.com ([2607:f8b0:4864:20::f41]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1kG4RM-0006oH-CT for linux-um@lists.infradead.org; Wed, 09 Sep 2020 18:03:29 +0000 Received: by mail-qv1-xf41.google.com with SMTP id cy2so2011015qvb.0 for ; Wed, 09 Sep 2020 11:03:27 -0700 (PDT) Date: Wed, 9 Sep 2020 15:03:24 -0300 From: Jason Gunthorpe Subject: Re: [RFC PATCH v2 1/3] mm/gup: fix gup_fast with dynamic page table folding Message-ID: <20200909180324.GI87483@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> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20200909192534.442f8984@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 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 Wed, Sep 09, 2020 at 07:25:34PM +0200, Gerald Schaefer wrote: > I actually had to draw myself a picture to get some hold of > this, or rather a walk-through with a certain pud-crossing > range in a folded 3-level scenario. Not sure if I would have > understood my explanation above w/o that, but I hope you can > make some sense out of it. Or draw yourself a picture :-) What I don't understand is how does anything work with S390 today? If the fix is only to change pxx_addr_end() then than generic code like mm/pagewalk.c will iterate over a *different list* of page table entries. It's choice of entries to look at is entirely driven by pxx_addr_end(). Which suggest to me that mm/pagewalk.c also doesn't work properly today on S390 and this issue is not really about stack variables? Fundamentally if pXX_offset() and pXX_addr_end() must be consistent together, if pXX_offset() is folded then pXX_addr_end() must cause a single iteration of that level. Jason _______________________________________________ linux-um mailing list linux-um@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-um