From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Tue, 9 Feb 2016 10:10:03 +0100 From: Ingo Molnar Subject: Re: [PATCH] x86/mm/vmfault: Make vmalloc_fault() handle large pages Message-ID: <20160209091003.GA10774@gmail.com> References: <1454976038-22486-1-git-send-email-toshi.kani@hpe.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1454976038-22486-1-git-send-email-toshi.kani@hpe.com> Sender: owner-linux-mm@kvack.org To: Toshi Kani Cc: tglx@linutronix.de, mingo@redhat.com, hpa@zytor.com, bp@alien8.de, henning.schild@siemens.com, linux-nvdimm@lists.01.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org List-ID: * Toshi Kani wrote: > Since 4.1, ioremap() supports large page (pud/pmd) mappings in x86_64 and PAE. > vmalloc_fault() however assumes that the vmalloc range is limited to pte > mappings. > > pgd_ctor() sets the kernel's pgd entries to user's during fork(), which makes > user processes share the same page tables for the kernel ranges. When a call to > ioremap() is made at run-time that leads to allocate a new 2nd level table (pud > in 64-bit and pmd in PAE), user process needs to re-sync with the updated kernel > pgd entry with vmalloc_fault(). > > Following changes are made to vmalloc_fault(). So what were the effects of this shortcoming? Were large page ioremap()s unusable? Was this harmless because no driver used this facility? If so then the changelog needs to spell this out clearly ... Thanks, Ingo -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756023AbcBIJKT (ORCPT ); Tue, 9 Feb 2016 04:10:19 -0500 Received: from mail-wm0-f65.google.com ([74.125.82.65]:34085 "EHLO mail-wm0-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755801AbcBIJKI (ORCPT ); Tue, 9 Feb 2016 04:10:08 -0500 Date: Tue, 9 Feb 2016 10:10:03 +0100 From: Ingo Molnar To: Toshi Kani Cc: tglx@linutronix.de, mingo@redhat.com, hpa@zytor.com, bp@alien8.de, henning.schild@siemens.com, linux-nvdimm@ml01.01.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] x86/mm/vmfault: Make vmalloc_fault() handle large pages Message-ID: <20160209091003.GA10774@gmail.com> References: <1454976038-22486-1-git-send-email-toshi.kani@hpe.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1454976038-22486-1-git-send-email-toshi.kani@hpe.com> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org * Toshi Kani wrote: > Since 4.1, ioremap() supports large page (pud/pmd) mappings in x86_64 and PAE. > vmalloc_fault() however assumes that the vmalloc range is limited to pte > mappings. > > pgd_ctor() sets the kernel's pgd entries to user's during fork(), which makes > user processes share the same page tables for the kernel ranges. When a call to > ioremap() is made at run-time that leads to allocate a new 2nd level table (pud > in 64-bit and pmd in PAE), user process needs to re-sync with the updated kernel > pgd entry with vmalloc_fault(). > > Following changes are made to vmalloc_fault(). So what were the effects of this shortcoming? Were large page ioremap()s unusable? Was this harmless because no driver used this facility? If so then the changelog needs to spell this out clearly ... Thanks, Ingo