Received: by 2002:a25:86ce:0:0:0:0:0 with SMTP id y14csp802024ybm; Wed, 22 May 2019 11:46:08 -0700 (PDT) X-Google-Smtp-Source: APXvYqwv6vnqYleuer19Ps/XCmVlBANUgnWxmZO190nukkWX5emHgDhtzNz+twAIChqG1MPPJfZp X-Received: by 2002:a17:902:8bc1:: with SMTP id r1mr25857952plo.163.1558550768730; Wed, 22 May 2019 11:46:08 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1558550768; cv=none; d=google.com; s=arc-20160816; b=xd8VRtuRzNPdhn8u3XrcLVxXbMYsla2Hp0dfpy0zaF4ppq27Mxh2zO+sLOME2R/Dzu pQCnS0KPsLu7u3KZevYNdozW5HcoJUOxJmVj19pz8P47yg0Gg1P5owmEWgyfly22OXWh EV+ZfBeS+ZQq4zjq5uCUd7AT4sTZASgNEJ75QDRQ6xBG+eIoTzBw6/DdLrVXV8HzAOF1 dCYvS8LKva0MUEm2cyS/4CBeoXzwbGzvdIVe2Hi9veaYOHzENT7xBvXjp5K6nMGuQdJq SmbszvcVU31MVSkwJ1IljWRoLDKhHDWjTaaOXY2ypG1i2ZOMMPvMAkLUBvzOa/wZmYE/ XArA== 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 :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject; bh=r9tffKpSR5//URn23d6p6EwP5wm+2fCjodocbQEgccA=; b=J4FvVMyIerll5EBd28pCAr8hCV67dzDE5pUT46HAA9Uk8GYK3uow7E2cjgqiWAcCrz UbR8anFjIPumgm90ramT84UbNG1FpYVKs4BajRhtwu4PU/9nRcg6bbMaQl9q0a3c2Fet Zb+9/PzwEy45zKE0fOSMgBrGRXBFq3BereqSfqlKOj94XPRoZNcEUBaoFM/0kkIuzWbc uE92jpM8FdYs0LoSEUuEDHJbazm2+0POfOk6vr0E+69Hs5koOMU5LHDVd/fhSmTYPgok 8JwvcPCFEAME2+bsVzcAg8HPC1r1649N/5Kfe86XwZqYgdzh0K8u9lXt/xvHFhPLF5uQ xuSQ== 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 b13si27945342pge.437.2019.05.22.11.45.53; Wed, 22 May 2019 11:46:08 -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 S1729559AbfEVSos (ORCPT + 99 others); Wed, 22 May 2019 14:44:48 -0400 Received: from mail-pl1-f195.google.com ([209.85.214.195]:46827 "EHLO mail-pl1-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729003AbfEVSos (ORCPT ); Wed, 22 May 2019 14:44:48 -0400 Received: by mail-pl1-f195.google.com with SMTP id r18so1477643pls.13 for ; Wed, 22 May 2019 11:44:47 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=r9tffKpSR5//URn23d6p6EwP5wm+2fCjodocbQEgccA=; b=pgktC7ufNXsZeXQspOl0RqFobN7vQ9YD8hhksJDnwHTb6yU6sZX5BbJAvb0GVWwB11 BbzCMzxXIAXm+jlG4ApHlfIB71Hj6s3dkDVZszCG1gy7zRghomj6R6h+s81Q1qIe67LD hY+djMkNG7v0ZzjpF5ZXdWEThGkTGEG7hjYDrWo/lB53K2udm6+JITEOHdAXulqjcw1J id7kCD9oM/iEkU4A+jBjy4kRVDFAYpCfu32fxsew6YhNJ30fy/MW15/y+0vAxC+aDCwm ajFz+vWXJnNbOdsyUgKzEdpTblQyW7bT/Lf7NOz6/SDp8Tc2UNunFidlW6U6PiI0GsY+ 46+g== X-Gm-Message-State: APjAAAU7lRIIIAtlJYm9nZY44iprhKhd/80ZzkWBIdgfPbZuHw35BzKD jTUqvN6i50a4Vr/BvH7CAavZNg== X-Received: by 2002:a17:902:100a:: with SMTP id b10mr89267682pla.239.1558550687269; Wed, 22 May 2019 11:44:47 -0700 (PDT) Received: from localhost.localdomain ([110.227.182.225]) by smtp.gmail.com with ESMTPSA id l65sm42599576pfb.7.2019.05.22.11.44.41 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 22 May 2019 11:44:46 -0700 (PDT) Subject: Re: [PATCH v2] vmcore: Add a kernel cmdline vmcore_device_dump To: Kairui Song , linux-kernel@vger.kernel.org Cc: Rahul Lakkireddy , "David S . Miller" , Eric Biederman , Alexey Dobriyan , Andrew Morton , Dave Young , "kexec@lists.infradead.org" References: <20190520061834.32231-1-kasong@redhat.com> From: Bhupesh Sharma Message-ID: <0c0fb7af-f386-bde1-46f6-1afa29782243@redhat.com> Date: Thu, 23 May 2019 00:14:39 +0530 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <20190520061834.32231-1-kasong@redhat.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 05/20/2019 11:48 AM, Kairui Song wrote: > 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 vmcore_device_dump= kernel parameter, and disable > device dump by default. User can enable it only if device dump data is > required for debugging, and have the chance to increase the kdump > reserved memory accordingly before device dump fails kdump. > > Signed-off-by: Kairui Song > --- > 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 | 15 +++++++++++++++ > fs/proc/vmcore.c | 13 +++++++++++++ > 2 files changed, 28 insertions(+) > > diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt > index 43176340c73d..2d48e39fd080 100644 > --- a/Documentation/admin-guide/kernel-parameters.txt > +++ b/Documentation/admin-guide/kernel-parameters.txt > @@ -5062,6 +5062,21 @@ > decrease the size and leave more room for directly > mapped kernel RAM. > > + vmcore_device_dump= > + [VMCORE] > + Format: {"off" | "on"} > + If CONFIG_PROC_VMCORE_DEVICE_DUMP is set, > + this parameter allows enable or disable device dump > + for vmcore. We can add a simpler description here, something like: Depends on CONFIG_PROC_VMCORE_DEVICE_DUMP > + Device dump allows drivers to append dump data to > + vmcore so you can collect driver specified debug info. > + Note that the drivers could append the data without > + any limit, and the data is stored in memory, this may > + bring a significant memory stress. If you want to turn > + on this option, make sure you have reserved enough memory > + with crashkernel= parameter. > + default: off ... and massage the rest of text accordingly. Better to also modify the help text for 'PROC_VMCORE_DEVICE_DUMP' config option defined in 'fs/proc/Kconfig'. Something like: config PROC_VMCORE_DEVICE_DUMP bool "Device Hardware/Firmware Log Collection" <..snip..> If you say Y here, the collected device dumps will be added as ELF notes to /proc/vmcore. If this option is selected, device dump collection can still be disabled by passing vmcore_device_dump=off to the kernel. See config INTEL_IOMMU_DEFAULT_ON in 'drivers/iommu/Kconfig' as an example. > vmcp_cma=nn[MG] [KNL,S390] > Sets the memory size reserved for contiguous memory > allocations for the vmcp device driver. > diff --git a/fs/proc/vmcore.c b/fs/proc/vmcore.c > index 3fe90443c1bb..d1b608b0efad 100644 > --- a/fs/proc/vmcore.c > +++ b/fs/proc/vmcore.c > @@ -53,6 +53,8 @@ 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_enabled; > #endif /* CONFIG_PROC_VMCORE_DEVICE_DUMP */ > > /* Device Dump Size */ > @@ -1451,6 +1453,11 @@ int vmcore_add_device_dump(struct vmcoredd_data *data) > size_t data_size; > int ret; > > + if (!vmcoredd_enabled) { > + pr_err_once("Device dump is disabled\n"); > + return -EINVAL; > + } > + > if (!data || !strlen(data->dump_name) || > !data->vmcoredd_callback || !data->size) > return -EINVAL; > @@ -1502,6 +1509,12 @@ int vmcore_add_device_dump(struct vmcoredd_data *data) > return ret; > } > EXPORT_SYMBOL(vmcore_add_device_dump); > + > +static int __init vmcoredd_parse_cmdline(char *arg) > +{ > + return kstrtobool(arg, &vmcoredd_enabled); > +} > +__setup("vmcore_device_dump=", vmcoredd_parse_cmdline); > #endif /* CONFIG_PROC_VMCORE_DEVICE_DUMP */ > > /* Free all dumps in vmcore device dump list */ > Thanks, Bhupesh