Received: by 2002:ac0:bc90:0:0:0:0:0 with SMTP id a16csp1487261img; Sat, 23 Mar 2019 04:18:15 -0700 (PDT) X-Google-Smtp-Source: APXvYqxgt+u6Z0YadXqCOZarWphQYlNEKyx7fnIQ7eJzpi76En0HAWrVs40XsUnQqCavdZb0RmJT X-Received: by 2002:a62:e411:: with SMTP id r17mr13973049pfh.127.1553339895627; Sat, 23 Mar 2019 04:18:15 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1553339895; cv=none; d=google.com; s=arc-20160816; b=aHFBUFNyvQn2SPhdqeud8Z3Xe4ZDlmdWYQQ3hVGOZ48lOsud8Me7M5FiAfHRXYEZ0i rmV0gNIUcjwRijUp66cclkSiKR4cDbDkPNAQhaLVzEerY2YfLAbYWjW/6+KmN7W33Age +9QWVrwInA0Od/+V7grbvz/PP2C6wryxndnP72EMoJ7cQIE9819tVe4hNpBkxcpcfslT vlKxDmFm32W7YEe8aKCWqNOW5S3GfI+gLYxGsWlw80WrfsRkcfZ0PuV9Fv2nqnzK33gg xn2mAdeTdShROHbggu5wQrxLnfv0ruhpIF0rCOXPr8JH5XP5AbIpq+ELDs4YLQSXRej8 0aKg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-disposition :content-transfer-encoding:mime-version:robot-unsubscribe:robot-id :git-commit-id:subject:to:references:in-reply-to:reply-to:cc :message-id:from:date; bh=VrNNrNRYyvT6RZDq9LXTkNhFhTM80Ora8usYAwXk/7c=; b=Gz4zRQlTnXYuX0eugRAJkyIGvwLif2zQmLQ5nyacAJvrP1e22iOBv46+LPH1ilIPcy u4KpomrxTo8UoWQ0Ipi6OZ5YQCj4xFkoB2qwTWpZHn2OPVvkhND8lSf/YVDEFKbjj8kz A5hPGZIvkOo1dt4lQG3fVWabKZVA0XtwWnEV49VpROHoMLZRchyBX2y8bhj1d+n/Ddsj B1XZZ94H3fWgyiVN18SOmAyw+jfiRqeB3tcyLnxElBrL2b29EuZVwGKMm9zYdg6sUYu3 wke4ppL0di63dIPLsqBtiIhXQ/KAjwIkCxXyjT0qPc08cqtVAMeqlvQaacvy8WFpFp19 aTTQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id o61si9875279pld.280.2019.03.23.04.18.00; Sat, 23 Mar 2019 04:18:15 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727509AbfCWLQk (ORCPT + 99 others); Sat, 23 Mar 2019 07:16:40 -0400 Received: from terminus.zytor.com ([198.137.202.136]:41309 "EHLO terminus.zytor.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727050AbfCWLQj (ORCPT ); Sat, 23 Mar 2019 07:16:39 -0400 Received: from terminus.zytor.com (localhost [127.0.0.1]) by terminus.zytor.com (8.15.2/8.15.2) with ESMTPS id x2NBGGPA991686 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Sat, 23 Mar 2019 04:16:16 -0700 Received: (from tipbot@localhost) by terminus.zytor.com (8.15.2/8.15.2/Submit) id x2NBGFQG991680; Sat, 23 Mar 2019 04:16:15 -0700 Date: Sat, 23 Mar 2019 04:16:15 -0700 X-Authentication-Warning: terminus.zytor.com: tipbot set sender to tipbot@zytor.com using -f From: tip-bot for Kairui Song Message-ID: Cc: dyoung@redhat.com, mingo@kernel.org, bp@alien8.de, jbohac@suse.cz, linux-kernel@vger.kernel.org, tglx@linutronix.de, adobriyan@gmail.com, kasong@redhat.com, bhe@redhat.com, hpa@zytor.com, akpm@linux-foundation.org, osandov@fb.com Reply-To: akpm@linux-foundation.org, osandov@fb.com, hpa@zytor.com, bhe@redhat.com, kasong@redhat.com, tglx@linutronix.de, linux-kernel@vger.kernel.org, adobriyan@gmail.com, bp@alien8.de, mingo@kernel.org, jbohac@suse.cz, dyoung@redhat.com In-Reply-To: <20190308030508.13548-1-kasong@redhat.com> References: <20190308030508.13548-1-kasong@redhat.com> To: linux-tip-commits@vger.kernel.org Subject: [tip:x86/urgent] x86/gart: Exclude GART aperture from kcore Git-Commit-ID: ffc8599aa9763f39f6736a79da4d1575e7006f9a 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 X-Spam-Status: No, score=-0.8 required=5.0 tests=ALL_TRUSTED,BAYES_00, FREEMAIL_FORGED_REPLYTO,T_DATE_IN_FUTURE_96_Q autolearn=no autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on terminus.zytor.com Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Commit-ID: ffc8599aa9763f39f6736a79da4d1575e7006f9a Gitweb: https://git.kernel.org/tip/ffc8599aa9763f39f6736a79da4d1575e7006f9a Author: Kairui Song AuthorDate: Fri, 8 Mar 2019 11:05:08 +0800 Committer: Thomas Gleixner CommitDate: Sat, 23 Mar 2019 12:11:49 +0100 x86/gart: Exclude GART aperture from kcore On machines where the GART aperture is mapped over physical RAM, /proc/kcore contains the GART aperture range. Accessing the GART range via /proc/kcore results in a kernel crash. vmcore used to have the same issue, until it was fixed with commit 2a3e83c6f96c ("x86/gart: Exclude GART aperture from vmcore")', leveraging existing hook infrastructure in vmcore to let /proc/vmcore return zeroes when attempting to read the aperture region, and so it won't read from the actual memory. Apply the same workaround for kcore. First implement the same hook infrastructure for kcore, then reuse the hook functions introduced in the previous vmcore fix. Just with some minor adjustment, rename some functions for more general usage, and simplify the hook infrastructure a bit as there is no module usage yet. Suggested-by: Baoquan He Signed-off-by: Kairui Song Signed-off-by: Thomas Gleixner Reviewed-by: Jiri Bohac Acked-by: Baoquan He Cc: Borislav Petkov Cc: "H. Peter Anvin" Cc: Alexey Dobriyan Cc: Andrew Morton Cc: Omar Sandoval Cc: Dave Young Link: https://lkml.kernel.org/r/20190308030508.13548-1-kasong@redhat.com --- arch/x86/kernel/aperture_64.c | 20 +++++++++++++------- fs/proc/kcore.c | 27 +++++++++++++++++++++++++++ include/linux/kcore.h | 2 ++ 3 files changed, 42 insertions(+), 7 deletions(-) diff --git a/arch/x86/kernel/aperture_64.c b/arch/x86/kernel/aperture_64.c index 58176b56354e..294ed4392a0e 100644 --- a/arch/x86/kernel/aperture_64.c +++ b/arch/x86/kernel/aperture_64.c @@ -14,6 +14,7 @@ #define pr_fmt(fmt) "AGP: " fmt #include +#include #include #include #include @@ -57,7 +58,7 @@ int fallback_aper_force __initdata; int fix_aperture __initdata = 1; -#ifdef CONFIG_PROC_VMCORE +#if defined(CONFIG_PROC_VMCORE) || defined(CONFIG_PROC_KCORE) /* * If the first kernel maps the aperture over e820 RAM, the kdump kernel will * use the same range because it will remain configured in the northbridge. @@ -66,20 +67,25 @@ int fix_aperture __initdata = 1; */ static unsigned long aperture_pfn_start, aperture_page_count; -static int gart_oldmem_pfn_is_ram(unsigned long pfn) +static int gart_mem_pfn_is_ram(unsigned long pfn) { return likely((pfn < aperture_pfn_start) || (pfn >= aperture_pfn_start + aperture_page_count)); } -static void exclude_from_vmcore(u64 aper_base, u32 aper_order) +static void __init exclude_from_core(u64 aper_base, u32 aper_order) { aperture_pfn_start = aper_base >> PAGE_SHIFT; aperture_page_count = (32 * 1024 * 1024) << aper_order >> PAGE_SHIFT; - WARN_ON(register_oldmem_pfn_is_ram(&gart_oldmem_pfn_is_ram)); +#ifdef CONFIG_PROC_VMCORE + WARN_ON(register_oldmem_pfn_is_ram(&gart_mem_pfn_is_ram)); +#endif +#ifdef CONFIG_PROC_KCORE + WARN_ON(register_mem_pfn_is_ram(&gart_mem_pfn_is_ram)); +#endif } #else -static void exclude_from_vmcore(u64 aper_base, u32 aper_order) +static void exclude_from_core(u64 aper_base, u32 aper_order) { } #endif @@ -474,7 +480,7 @@ out: * may have allocated the range over its e820 RAM * and fixed up the northbridge */ - exclude_from_vmcore(last_aper_base, last_aper_order); + exclude_from_core(last_aper_base, last_aper_order); return 1; } @@ -520,7 +526,7 @@ out: * overlap with the first kernel's memory. We can't access the * range through vmcore even though it should be part of the dump. */ - exclude_from_vmcore(aper_alloc, aper_order); + exclude_from_core(aper_alloc, aper_order); /* Fix up the north bridges */ for (i = 0; i < amd_nb_bus_dev_ranges[i].dev_limit; i++) { diff --git a/fs/proc/kcore.c b/fs/proc/kcore.c index bbcc185062bb..d29d869abec1 100644 --- a/fs/proc/kcore.c +++ b/fs/proc/kcore.c @@ -54,6 +54,28 @@ static LIST_HEAD(kclist_head); static DECLARE_RWSEM(kclist_lock); static int kcore_need_update = 1; +/* + * Returns > 0 for RAM pages, 0 for non-RAM pages, < 0 on error + * Same as oldmem_pfn_is_ram in vmcore + */ +static int (*mem_pfn_is_ram)(unsigned long pfn); + +int __init register_mem_pfn_is_ram(int (*fn)(unsigned long pfn)) +{ + if (mem_pfn_is_ram) + return -EBUSY; + mem_pfn_is_ram = fn; + return 0; +} + +static int pfn_is_ram(unsigned long pfn) +{ + if (mem_pfn_is_ram) + return mem_pfn_is_ram(pfn); + else + return 1; +} + /* This doesn't grab kclist_lock, so it should only be used at init time. */ void __init kclist_add(struct kcore_list *new, void *addr, size_t size, int type) @@ -465,6 +487,11 @@ read_kcore(struct file *file, char __user *buffer, size_t buflen, loff_t *fpos) goto out; } m = NULL; /* skip the list anchor */ + } else if (!pfn_is_ram(__pa(start) >> PAGE_SHIFT)) { + if (clear_user(buffer, tsz)) { + ret = -EFAULT; + goto out; + } } else if (m->type == KCORE_VMALLOC) { vread(buf, (char *)start, tsz); /* we have to zero-fill user buffer even if no read */ diff --git a/include/linux/kcore.h b/include/linux/kcore.h index 8c3f8c14eeaa..c843f4a9c512 100644 --- a/include/linux/kcore.h +++ b/include/linux/kcore.h @@ -44,6 +44,8 @@ void kclist_add_remap(struct kcore_list *m, void *addr, void *vaddr, size_t sz) m->vaddr = (unsigned long)vaddr; kclist_add(m, addr, sz, KCORE_REMAP); } + +extern int __init register_mem_pfn_is_ram(int (*fn)(unsigned long pfn)); #else static inline void kclist_add(struct kcore_list *new, void *addr, size_t size, int type)