From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753486AbeAZPJ0 (ORCPT ); Fri, 26 Jan 2018 10:09:26 -0500 Received: from terminus.zytor.com ([65.50.211.136]:45595 "EHLO terminus.zytor.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752024AbeAZPJZ (ORCPT ); Fri, 26 Jan 2018 10:09:25 -0500 Date: Fri, 26 Jan 2018 07:07:12 -0800 From: tip-bot for Andy Lutomirski Message-ID: Cc: bp@alien8.de, mingo@kernel.org, tglx@linutronix.de, dave.hansen@intel.com, luto@kernel.org, neil.berrington@datacore.com, khlebnikov@yandex-team.ru, linux-kernel@vger.kernel.org, hpa@zytor.com Reply-To: bp@alien8.de, dave.hansen@intel.com, mingo@kernel.org, tglx@linutronix.de, neil.berrington@datacore.com, luto@kernel.org, linux-kernel@vger.kernel.org, khlebnikov@yandex-team.ru, hpa@zytor.com In-Reply-To: <2ae598f8c279b0a29baf75df207e6f2fdddc0a1b.1516914529.git.luto@kernel.org> References: <2ae598f8c279b0a29baf75df207e6f2fdddc0a1b.1516914529.git.luto@kernel.org> To: linux-tip-commits@vger.kernel.org Subject: [tip:x86/urgent] x86/mm/64: Tighten up vmalloc_fault() sanity checks on 5-level kernels Git-Commit-ID: 36b3a7726886f24c4209852a58e64435bde3af98 X-Mailer: tip-git-log-daemon Robot-ID: Robot-Unsubscribe: Contact to get blacklisted from these emails MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 Content-Disposition: inline Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Commit-ID: 36b3a7726886f24c4209852a58e64435bde3af98 Gitweb: https://git.kernel.org/tip/36b3a7726886f24c4209852a58e64435bde3af98 Author: Andy Lutomirski AuthorDate: Thu, 25 Jan 2018 13:12:15 -0800 Committer: Thomas Gleixner CommitDate: Fri, 26 Jan 2018 15:56:23 +0100 x86/mm/64: Tighten up vmalloc_fault() sanity checks on 5-level kernels On a 5-level kernel, if a non-init mm has a top-level entry, it needs to match init_mm's, but the vmalloc_fault() code skipped over the BUG_ON() that would have checked it. While we're at it, get rid of the rather confusing 4-level folded "pgd" logic. Cleans-up: b50858ce3e2a ("x86/mm/vmalloc: Add 5-level paging support") Signed-off-by: Andy Lutomirski Signed-off-by: Thomas Gleixner Cc: Konstantin Khlebnikov Cc: Dave Hansen Cc: Borislav Petkov Cc: Neil Berrington Link: https://lkml.kernel.org/r/2ae598f8c279b0a29baf75df207e6f2fdddc0a1b.1516914529.git.luto@kernel.org --- arch/x86/mm/fault.c | 22 +++++++++------------- 1 file changed, 9 insertions(+), 13 deletions(-) diff --git a/arch/x86/mm/fault.c b/arch/x86/mm/fault.c index b3e4077..800de81 100644 --- a/arch/x86/mm/fault.c +++ b/arch/x86/mm/fault.c @@ -439,18 +439,13 @@ static noinline int vmalloc_fault(unsigned long address) if (pgd_none(*pgd_ref)) return -1; - if (pgd_none(*pgd)) { - set_pgd(pgd, *pgd_ref); - arch_flush_lazy_mmu_mode(); - } else if (CONFIG_PGTABLE_LEVELS > 4) { - /* - * With folded p4d, pgd_none() is always false, so the pgd may - * point to an empty page table entry and pgd_page_vaddr() - * will return garbage. - * - * We will do the correct sanity check on the p4d level. - */ - BUG_ON(pgd_page_vaddr(*pgd) != pgd_page_vaddr(*pgd_ref)); + if (CONFIG_PGTABLE_LEVELS > 4) { + if (pgd_none(*pgd)) { + set_pgd(pgd, *pgd_ref); + arch_flush_lazy_mmu_mode(); + } else { + BUG_ON(pgd_page_vaddr(*pgd) != pgd_page_vaddr(*pgd_ref)); + } } /* With 4-level paging, copying happens on the p4d level. */ @@ -459,7 +454,7 @@ static noinline int vmalloc_fault(unsigned long address) if (p4d_none(*p4d_ref)) return -1; - if (p4d_none(*p4d)) { + if (p4d_none(*p4d) && CONFIG_PGTABLE_LEVELS == 4) { set_p4d(p4d, *p4d_ref); arch_flush_lazy_mmu_mode(); } else { @@ -470,6 +465,7 @@ static noinline int vmalloc_fault(unsigned long address) * Below here mismatches are bugs because these lower tables * are shared: */ + BUILD_BUG_ON(CONFIG_PGTABLE_LEVELS < 4); pud = pud_offset(p4d, address); pud_ref = pud_offset(p4d_ref, address);