Received: by 2002:a25:ab43:0:0:0:0:0 with SMTP id u61csp561460ybi; Thu, 30 May 2019 03:06:53 -0700 (PDT) X-Google-Smtp-Source: APXvYqxMkVdHZ+A0elh4P4NPGbQNjDoZH0+y6LQHvXE3GKI90BiKvsOjMMbEqLqJgLAuO2YWd3NK X-Received: by 2002:a17:90a:c481:: with SMTP id j1mr2976765pjt.96.1559210813661; Thu, 30 May 2019 03:06:53 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1559210813; cv=none; d=google.com; s=arc-20160816; b=Kf8x9GZO/0/YY/F78bgdKejXe6f21io8HMRdj6veT9Ythu1cef0y2aKtOtnPq3im+v P8Ovf6t/VxoqOWtpNBTG98B4tbidhqi4BNaclQRK8tvj/7Al65wNf3eZBxVCPZqxyPzv b/NrbH9YLaibgtdTstHfRq7lbu/bf4bblAObzs9nsVRPj4ycTokXbUeH7ZMmkyo6dJT5 V8Kt6SpDLeGCCIN7Jhl52pPot7x8XWT4sQ8lBWf0IOSvkcWSL/XGZy2ZKBCos5Bif2Z3 +icyil5qmQvsif7mnei4zquRHOCOV718oZPGYIkKYUjD9fr2snc0MqsAmVV892Y/y3PW Bw5A== 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=D3fAyF6u8uC4bNp5Lwkfrz0eyQDvEozNG2184y/ICi8=; b=RDH26eG7emDfB7fZMDM78B94KZQQVxEl5iciE1Ktiwv646bMCUxBf+0GxbL7MK+M7Y fnj1GZBr7emNAuhFmfiP+ZGiL9/MnorBtMgUsb21XsnixkQKvFY0Zc/0hphxo/TzeMY4 h6jqihDgyFpy3aRTv1lWaWqYzDInEE9uYZ6cYHoy5R+HXfwoNe3dyMbtxUEme2No+Rbc lD2FMOzYW1IcahGvVNR+wFb69bLifi1LzmjN5maEfKMyPyDeca6ICwEK0nWb9qDYyI/R ffv9neKpydoSiGQ6egm5jtnUQtGGsqqJk21WCxztMCy2TF/HSOR75+qciNR9867h1y4D LsKw== 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 cm24si2399409pjb.106.2019.05.30.03.06.36; Thu, 30 May 2019 03:06:53 -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 S1727671AbfE3KEt (ORCPT + 99 others); Thu, 30 May 2019 06:04:49 -0400 Received: from mx1.redhat.com ([209.132.183.28]:54148 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725440AbfE3KEt (ORCPT ); Thu, 30 May 2019 06:04:49 -0400 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 846329D0F7; Thu, 30 May 2019 10:04:42 +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 32A497D54C; Thu, 30 May 2019 10:04:35 +0000 (UTC) From: Kairui Song To: Andrew Morton Cc: Rahul Lakkireddy , "David S . Miller" , Eric Biederman , Alexey Dobriyan , Dave Young , Bhupesh Sharma , Baoquan He , linux-kernel@vger.kernel.org, Kairui Song Subject: [PATCH v5] vmcore: Add a kernel parameter novmcoredd Date: Thu, 30 May 2019 18:03:39 +0800 Message-Id: <20190530100339.3089-1-kasong@redhat.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.39]); Thu, 30 May 2019 10:04:49 +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 Reviewed-by: Bhupesh Sharma Acked-by: Dave Young --- Hi Andrew, sorry for the trouble but could you help pick up this one instead for "vmcore: Add a kernel parameter novmcoredd" patch? Previous one is in mm tree but failed compile when CONFIG_MODULES is not set, I fixed this issue and carried something else like your doc fix, thanks! Update from V4: - Document adjust by Andrew Morton, also move the text to a better position - Fix compile error when CONFIG_MODULES is not set - Return EPERM instead of EINVAL when device dump is disabled as suggested by Dave Young 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 | 9 +++++++++ 3 files changed, 22 insertions(+), 1 deletion(-) diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt index 138f6664b2e2..90b25234d965 100644 --- a/Documentation/admin-guide/kernel-parameters.txt +++ b/Documentation/admin-guide/kernel-parameters.txt @@ -3088,6 +3088,17 @@ nosync [HW,M68K] Disables sync negotiation for all devices. + novmcoredd [KNL,KDUMP] + Disable device dump. Device dump allows drivers to + append dump data to vmcore so you can collect driver + specified debug info. Drivers can append the data + without any limit and this data is stored in memory, + so this may cause significant memory stress. Disabling + device dump can help save memory but the driver debug + data will be no longer available. This parameter + is only available when CONFIG_PROC_VMCORE_DEVICE_DUMP + is set. + nowatchdog [KNL] Disable both lockup detectors, i.e. soft-lockup and NMI watchdog (hard-lockup). diff --git a/fs/proc/Kconfig b/fs/proc/Kconfig index 62ee41b4bbd0..b74ea844abd5 100644 --- a/fs/proc/Kconfig +++ b/fs/proc/Kconfig @@ -58,7 +58,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 disable device + dump using the kernel 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 7bb96fdd38ad..936e9dbbfbec 100644 --- a/fs/proc/vmcore.c +++ b/fs/proc/vmcore.c @@ -26,6 +26,7 @@ #include #include #include +#include #include #include #include "internal.h" @@ -54,6 +55,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 */ @@ -1452,6 +1456,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 -EPERM; + } + if (!data || !strlen(data->dump_name) || !data->vmcoredd_callback || !data->size) return -EINVAL; -- 2.21.0