From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from hqnvemgate26.nvidia.com ([216.228.121.65]:14255 "EHLO hqnvemgate26.nvidia.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728254AbgIJVWw (ORCPT ); Thu, 10 Sep 2020 17:22:52 -0400 Subject: Re: [RFC PATCH v2 1/3] mm/gup: fix gup_fast with dynamic page table folding 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> <20200910181319.GO87483@ziepe.ca> From: John Hubbard Message-ID: <0c9bcb54-914b-e582-dd6d-3861267b6c94@nvidia.com> Date: Thu, 10 Sep 2020 14:22:37 -0700 MIME-Version: 1.0 In-Reply-To: <20200910181319.GO87483@ziepe.ca> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-s390-owner@vger.kernel.org List-ID: To: Jason Gunthorpe , Linus Torvalds Cc: Alexander Gordeev , Gerald Schaefer , Dave Hansen , LKML , linux-mm , linux-arch , Andrew Morton , 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 9/10/20 11:13 AM, Jason Gunthorpe wrote: > On Thu, Sep 10, 2020 at 10:35:38AM -0700, Linus Torvalds wrote: >> On Thu, Sep 10, 2020 at 2:40 AM Alexander Gordeev >> wrote: >>> >>> It is only gup_fast case that exposes the issue. It hits because >>> pointers to stack copies are passed to gup_pXd_range iterators, not >>> pointers to real page tables itself. >> >> Can we possibly change fast-gup to not do the stack copies? >> >> I'd actually rather do something like that, than the "addr_end" thing. > >> As you say, none of the other page table walking code does what the >> GUP code does, and I don't think it's required. > > As I understand it, the requirement is because fast-gup walks without > the page table spinlock, or mmap_sem held so it must READ_ONCE the > *pXX. > > It then checks that it is a valid page table pointer, then calls > pXX_offset(). > > The arch implementation of pXX_offset() derefs again the passed pXX > pointer. So it defeats the READ_ONCE and the 2nd load could observe > something that is no longer a page table pointer and crash. Just to be clear, though, that makes it sound a little wilder and reckless than it really is, right? Because actually, the page tables cannot be freed while gup_fast is walking them, due to either IPI blocking during the walk, or the moral equivalent (MMU_GATHER_RCU_TABLE_FREE) for non-IPI architectures. So the pages tables can *change* underneath gup_fast, and for example pages can be unmapped. But they remain valid page tables, it's just that their contents are unstable. Even if pXd_none()==true. Or am I way off here, and it really is possible (aside from the current s390 situation) to observe something that "is no longer a page table"? thanks, -- John Hubbard NVIDIA