From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Morton Subject: Re: [PATCH v3 2/7] mm/vmalloc: Track which page-table levels were modified Date: Mon, 18 May 2020 15:18:28 -0700 Message-ID: <20200518151828.ad3c714a29209b359e326ec4@linux-foundation.org> References: <20200515140023.25469-1-joro@8bytes.org> <20200515140023.25469-3-joro@8bytes.org> <20200515130142.4ca90ee590e9d8ab88497676@linux-foundation.org> <20200516125641.GK8135@suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20200516125641.GK8135@suse.de> Sender: linux-acpi-owner@vger.kernel.org To: Joerg Roedel Cc: Joerg Roedel , x86@kernel.org, hpa@zytor.com, Dave Hansen , Andy Lutomirski , Peter Zijlstra , rjw@rjwysocki.net, Arnd Bergmann , Steven Rostedt , Vlastimil Babka , Michal Hocko , Matthew Wilcox , linux-kernel@vger.kernel.org, linux-acpi@vger.kernel.org, linux-arch@vger.kernel.org, linux-mm@kvack.org, Christoph Hellwig List-Id: linux-arch.vger.kernel.org On Sat, 16 May 2020 14:56:41 +0200 Joerg Roedel wrote: > Hi Andrew, > > On Fri, May 15, 2020 at 01:01:42PM -0700, Andrew Morton wrote: > > On Fri, 15 May 2020 16:00:18 +0200 Joerg Roedel wrote: > > Lots of collisions here with Christoph's "decruft the vmalloc API" series > > (http://lkml.kernel.org/r/20200414131348.444715-1-hch@lst.de). > > > > I attempted to fix things up. > > > > unmap_kernel_range_noflush() needed to be redone. > > > > map_kernel_range_noflush() might need the arch_sync_kernel_mappings() call? > > Yes, map_kernel_range_noflush() needs the arch_sync_kernel_mappings() > call as well. > This? --- a/mm/vmalloc.c~mm-vmalloc-track-which-page-table-levels-were-modified-fix +++ a/mm/vmalloc.c @@ -309,6 +309,9 @@ int map_kernel_range_noflush(unsigned lo return err; } while (pgd++, addr = next, addr != end); + if (mask & ARCH_PAGE_TABLE_SYNC_MASK) + arch_sync_kernel_mappings(start, end); + return 0; } It would be nice to get all this (ie, linux-next) retested before we send it upstream, please. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Mon, 18 May 2020 15:18:28 -0700 From: Andrew Morton Subject: Re: [PATCH v3 2/7] mm/vmalloc: Track which page-table levels were modified Message-ID: <20200518151828.ad3c714a29209b359e326ec4@linux-foundation.org> In-Reply-To: <20200516125641.GK8135@suse.de> References: <20200515140023.25469-1-joro@8bytes.org> <20200515140023.25469-3-joro@8bytes.org> <20200515130142.4ca90ee590e9d8ab88497676@linux-foundation.org> <20200516125641.GK8135@suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org To: Joerg Roedel Cc: Joerg Roedel , x86@kernel.org, hpa@zytor.com, Dave Hansen , Andy Lutomirski , Peter Zijlstra , rjw@rjwysocki.net, Arnd Bergmann , Steven Rostedt , Vlastimil Babka , Michal Hocko , Matthew Wilcox , linux-kernel@vger.kernel.org, linux-acpi@vger.kernel.org, linux-arch@vger.kernel.org, linux-mm@kvack.org, Christoph Hellwig List-ID: Message-ID: <20200518221828.iFZoXv1XfrdrgvuxBswXDX4oGdHQbXpngm2APA7qVpE@z> On Sat, 16 May 2020 14:56:41 +0200 Joerg Roedel wrote: > Hi Andrew, > > On Fri, May 15, 2020 at 01:01:42PM -0700, Andrew Morton wrote: > > On Fri, 15 May 2020 16:00:18 +0200 Joerg Roedel wrote: > > Lots of collisions here with Christoph's "decruft the vmalloc API" series > > (http://lkml.kernel.org/r/20200414131348.444715-1-hch@lst.de). > > > > I attempted to fix things up. > > > > unmap_kernel_range_noflush() needed to be redone. > > > > map_kernel_range_noflush() might need the arch_sync_kernel_mappings() call? > > Yes, map_kernel_range_noflush() needs the arch_sync_kernel_mappings() > call as well. > This? --- a/mm/vmalloc.c~mm-vmalloc-track-which-page-table-levels-were-modified-fix +++ a/mm/vmalloc.c @@ -309,6 +309,9 @@ int map_kernel_range_noflush(unsigned lo return err; } while (pgd++, addr = next, addr != end); + if (mask & ARCH_PAGE_TABLE_SYNC_MASK) + arch_sync_kernel_mappings(start, end); + return 0; } It would be nice to get all this (ie, linux-next) retested before we send it upstream, please.