From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Wed, 9 Sep 2020 14:29:04 +0200 From: Gerald Schaefer Subject: Re: [RFC PATCH v2 1/3] mm/gup: fix gup_fast with dynamic page table folding Message-ID: <20200909142904.00b72921@thinkpad> In-Reply-To: <0dbc6ec8-45ea-0853-4856-2bc1e661a5a5@intel.com> References: <20200907180058.64880-1-gerald.schaefer@linux.ibm.com> <20200907180058.64880-2-gerald.schaefer@linux.ibm.com> <0dbc6ec8-45ea-0853-4856-2bc1e661a5a5@intel.com> MIME-Version: 1.0 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: Dave Hansen Cc: Peter Zijlstra , Benjamin Herrenschmidt , Dave Hansen , linux-mm , Paul Mackerras , linux-sparc , Alexander Gordeev , Claudio Imbrenda , Will Deacon , linux-arch , linux-s390 , Vasily Gorbik , Christian Borntraeger , Richard Weinberger , linux-x86 , Russell King , Jason Gunthorpe , 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-power , LKML , Michael Ellerman , Andrew Morton , Linus Torvalds , Mike Rapoport On Tue, 8 Sep 2020 07:30:50 -0700 Dave Hansen wrote: > On 9/7/20 11:00 AM, Gerald Schaefer wrote: > > 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. > > Would it be fair to say that the "fake" page table entries s390 > allocates on the stack are what's causing the trouble here? That might > be a nice thing to open up with here. "Dynamic page table folding" > really means nothing to me. Sorry, I guess my previous reply does not really explain "what the heck is dynamic page table folding?". On s390, we can have different number of page table levels for different processes / mms. We always start with 3 levels, and update dynamically on process demand to 4 or 5 levels, hence the dynamic folding. Still, the PxD_SIZE/SHIFT is defined statically, so that e.g. pXd_addr_end() will not reflect this dynamic behavior. For the various pagetable walkers using pXd_addr_end() (w/o READ_ONCE logic) this is no problem. With static folding, iteration over the folded levels will always happen at pgd level (top-level folding). For s390, we stay at the respective level and iterate there (dynamic middle-level folding), only return to pgd level if there really were 5 levels. This only works well as long there are real pagetable pointers involved, that can also be used for iteration. For gup_fast, or any other future pagetable walkers using the READ_ONCE logic w/o lock, that is not true. There are pointers involved to local pXd values on the stack, because of the READ_ONCE logic, and our middle-level iteration will suddenly iterate over such stack pointers instead of pagetable pointers. This will be addressed by making the pXd_addr_end() dynamic, for which we need to see the pXd value in order to determine its level / type. _______________________________________________ linux-um mailing list linux-um@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-um