Received: by 2002:a25:ab43:0:0:0:0:0 with SMTP id u61csp4896578ybi; Tue, 28 May 2019 04:25:33 -0700 (PDT) X-Google-Smtp-Source: APXvYqw3IV9R+U59NgwqrBQEBTSLyxdHvK17NVr4xkFe0oDmLQLLifXGMybLIixfPOedlAzsfuPQ X-Received: by 2002:a17:90a:cb10:: with SMTP id z16mr5070480pjt.81.1559042733267; Tue, 28 May 2019 04:25:33 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1559042733; cv=none; d=google.com; s=arc-20160816; b=JeaXaJyrbhagsnuz5R4HlA8xieqNMaJrmq5Q5SCeCIHeCKnGQyvV0D1iLpeN6yD2Bg 2cMwrvbnO8wvAXJFwp2AnoOUt7p6rTKPALSZCYUw201mgOhFp8ftN4ipOv9aFJvlkn72 +08ymonq2SLTRRXR488iTrmMnmY0vIKrD0B5WlC9STTns/s1EVCZrYnvQU59U6DA7qcu ihB3c1aeDaGZGD8qE8qukupnLM23avoK9gMIO25MrdaJwxMu6Vxcth4a5K3kYUXxT8ZP G0I/PDYIx/fPGIyHp/3yXnbfL46lGDxRduvlXW2+ZiC6rkmDIf3hrwy7eRc4lBzfP1E6 JSvg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from; bh=SXBj6RLchJCJbKMdVWWqf8BSGVSjfI1hVV4y7YVOS/4=; b=wpxa3cYUuxRuYryQSXqAPvjAh9SfNpMA2gkCT7T28bn+LmvrnZdIJck4fwqzwWx8F8 XAtQV5Joj+97ZbWlshFuPIB6NVtB9OPMu7E6ojn2EOQnP0BoX4Bykm28thrKCo3lfCR0 RqPj1vwzMZpqphDS5PTxnfyXjY5pXbdnpKqiGQQ8Ip69O/Oytecn57875x3/3o0cIikE 7RoouH/FcK6fEP1vGokIuRMUAMAkYLiCGW4UHEwgocwywMJfFpqHIBUOR+1GX/LzWP4W V1rKmV8FTEusG3RaM0thxIv4XvIo5Aj77i96TZ6q4XEss1rntawX7XgTzFnu9GarCLDk W7VQ== 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id p91si23529363plb.165.2019.05.28.04.25.17; Tue, 28 May 2019 04:25:33 -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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726698AbfE1LWv (ORCPT + 99 others); Tue, 28 May 2019 07:22:51 -0400 Received: from mx1.redhat.com ([209.132.183.28]:47650 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726313AbfE1LWu (ORCPT ); Tue, 28 May 2019 07:22:50 -0400 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 6471B81126; Tue, 28 May 2019 11:22:40 +0000 (UTC) Received: from kasong-rh-laptop.pek2.redhat.com (wlc-trust-154.pek2.redhat.com [10.72.3.154]) by smtp.corp.redhat.com (Postfix) with ESMTP id 980967C0B4; Tue, 28 May 2019 11:22:32 +0000 (UTC) From: Kairui Song To: linux-kernel@vger.kernel.org Cc: Rahul Lakkireddy , "David S . Miller" , Eric Biederman , Alexey Dobriyan , Andrew Morton , Dave Young , "kexec@lists.infradead.org" , Bhupesh Sharma , Baoquan He , Kairui Song Subject: [PATCH v4] vmcore: Add a kernel parameter novmcoredd Date: Tue, 28 May 2019 19:18:56 +0800 Message-Id: <20190528111856.7276-1-kasong@redhat.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.28]); Tue, 28 May 2019 11:22:50 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Since commit 2724273e8fd0 ("vmcore: add API to collect hardware dump in second kernel"), drivers is allowed to add device related dump data to vmcore as they want by using the device dump API. This have a potential issue, the data is stored in memory, drivers may append too much data and use too much memory. The vmcore is typically used in a kdump kernel which runs in a pre-reserved small chunk of memory. So as a result it will make kdump unusable at all due to OOM issues. So introduce new 'novmcoredd' command line option. User can disable device dump to reduce memory usage. This is helpful if device dump is using too much memory, disabling device dump could make sure a regular vmcore without device dump data is still available. Signed-off-by: Kairui Song --- Update from V3: - Use novmcoredd instead of vmcore_device_dump. Use vmcore_device_dump and make it off by default is confusing, novmcoredd is a cleaner way to let user space be able to disable device dump to save memory. Update from V2: - Improve related docs Update from V1: - Use bool parameter to turn it on/off instead of letting user give the size limit. Size of device dump is hard to determine. Documentation/admin-guide/kernel-parameters.txt | 11 +++++++++++ fs/proc/Kconfig | 3 ++- fs/proc/vmcore.c | 8 ++++++++ 3 files changed, 21 insertions(+), 1 deletion(-) diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt index 138f6664b2e2..1b900d262680 100644 --- a/Documentation/admin-guide/kernel-parameters.txt +++ b/Documentation/admin-guide/kernel-parameters.txt @@ -2872,6 +2872,17 @@ /sys/module/printk/parameters/console_suspend) to turn on/off it dynamically. + novmcoredd [KNL,KDUMP] + Disable device dump. Device dump allows drivers to + append dump data to vmcore so you can collect driver + specified debug info. The drivers could append the + data without any limit, and the data is stored in + memory, this may bring a significant memory stress. + Disable device dump can help save memory but driver + debug data will be no longer available. + Only available when CONFIG_PROC_VMCORE_DEVICE_DUMP + is set. + noaliencache [MM, NUMA, SLAB] Disables the allocation of alien caches in the slab allocator. Saves per-node memory, but will impact performance. diff --git a/fs/proc/Kconfig b/fs/proc/Kconfig index 817c02b13b1d..62b19162d198 100644 --- a/fs/proc/Kconfig +++ b/fs/proc/Kconfig @@ -57,7 +57,8 @@ config PROC_VMCORE_DEVICE_DUMP snapshot. If you say Y here, the collected device dumps will be added - as ELF notes to /proc/vmcore. + as ELF notes to /proc/vmcore. You can still disabled device + dump by command line option 'novmcoredd'. config PROC_SYSCTL bool "Sysctl support (/proc/sys)" if EXPERT diff --git a/fs/proc/vmcore.c b/fs/proc/vmcore.c index 3fe90443c1bb..e815fd035fc0 100644 --- a/fs/proc/vmcore.c +++ b/fs/proc/vmcore.c @@ -53,6 +53,9 @@ static struct proc_dir_entry *proc_vmcore; /* Device Dump list and mutex to synchronize access to list */ static LIST_HEAD(vmcoredd_list); static DEFINE_MUTEX(vmcoredd_mutex); + +static bool vmcoredd_disabled; +core_param(novmcoredd, vmcoredd_disabled, bool, 0); #endif /* CONFIG_PROC_VMCORE_DEVICE_DUMP */ /* Device Dump Size */ @@ -1451,6 +1454,11 @@ int vmcore_add_device_dump(struct vmcoredd_data *data) size_t data_size; int ret; + if (vmcoredd_disabled) { + pr_err_once("Device dump is disabled\n"); + return -EINVAL; + } + if (!data || !strlen(data->dump_name) || !data->vmcoredd_callback || !data->size) return -EINVAL; -- 2.21.0