Received: by 2002:a25:86ce:0:0:0:0:0 with SMTP id y14csp64682ybm; Tue, 21 May 2019 22:40:58 -0700 (PDT) X-Google-Smtp-Source: APXvYqzttyEMRWBuCy2dVOV2LCo0doqm6CaxHvPKq22CrY1fbbONDRwTtp9nXAUHsTa2h/O0qSVD X-Received: by 2002:a63:2224:: with SMTP id i36mr18695601pgi.289.1558503658349; Tue, 21 May 2019 22:40:58 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1558503658; cv=none; d=google.com; s=arc-20160816; b=TiLQLMulFa1CVhQeoncYett+1kXu4G4v8060N0O5E7iDu2HKckvUM71TqK1objGXPn D8JaUpiqW5kfui4yM3CxuxyudnvAmvgf0tLoZrX3gZ5MthVyU6yossL6gB7dJTP6TkzV o+Q+WAzP9QRhG14o3NoCDQR+nGRekQRh+msb4zB1ozGls8AuWHUExdZn+0WyWhncUISL byGWzBx0QGf4VAMytlmKB/s/tTSvrzIpyviuwAkDd+iY/iUg346XlnSdCJhOLt+0p6Uy ilH8w2vHzBM9cPaVbix9ovgLtEQOV3yfZtA4xEuKfIntgXdfWyAFDVyFZ2rn64lhSYf/ 6UKg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=6Y7qWdYmgVZ3C5PQkmgojKGAhltDBwRIF2KL6w2JfUI=; b=v2e0lnUdFJt1CQ8VQh6zW9b2XiC7bTJfCl+R5aWTOz1tkQFLYUar/CQIX6Y8iAXScp CK+VWgOJjHW0kKZXNpHbfngDItoFdzfe7IpWyP2jHXVGEU4t0rShQH/E2mBpeay2qlai 0t2h4tar310BodDR3hv5wW7d/i3Gl8H/koz4tPQZzMeM602I8TRlGU7QJAltMTMD06Lo BfdNrmitJcmyrkXt3NWuGjoxsvu2JhUMe3wb0xRLUlgsNKxZDaSim9Ir8qJgyWlN1bJR 2CHUSh/OxtZ2e761FNuzBqtVWxeifbhzUoBP9x3shKOo1XVESk1DN3oilky3gjNqLtSS O4yA== 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 c20si26220221pfn.256.2019.05.21.22.40.42; Tue, 21 May 2019 22:40:58 -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 S1726358AbfEVFie (ORCPT + 99 others); Wed, 22 May 2019 01:38:34 -0400 Received: from mx1.redhat.com ([209.132.183.28]:36202 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725796AbfEVFie (ORCPT ); Wed, 22 May 2019 01:38:34 -0400 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id A8BA166991; Wed, 22 May 2019 05:38:30 +0000 (UTC) Received: from dhcp-128-65.nay.redhat.com (ovpn-12-78.pek2.redhat.com [10.72.12.78]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 608DA66845; Wed, 22 May 2019 05:38:26 +0000 (UTC) Date: Wed, 22 May 2019 13:38:22 +0800 From: Dave Young To: Kairui Song Cc: linux-kernel@vger.kernel.org, Rahul Lakkireddy , "David S . Miller" , Eric Biederman , Alexey Dobriyan , Andrew Morton , "kexec@lists.infradead.org" , Bhupesh Sharma Subject: Re: [PATCH v2] vmcore: Add a kernel cmdline vmcore_device_dump Message-ID: <20190522053822.GA4472@dhcp-128-65.nay.redhat.com> References: <20190520061834.32231-1-kasong@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190520061834.32231-1-kasong@redhat.com> User-Agent: Mutt/1.11.3 (2019-02-01) X-Scanned-By: MIMEDefang 2.79 on 10.5.11.16 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.38]); Wed, 22 May 2019 05:38:33 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 05/20/19 at 02:18pm, 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] It looks better to have above two line merged in one line, also use [KNL, KDUMP] will be better. > + Format: {"off" | "on"} > + If CONFIG_PROC_VMCORE_DEVICE_DUMP is set, > + this parameter allows enable or disable device dump > + for vmcore. > + 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 > + > 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 */ > -- > 2.21.0 > Thanks Dave