Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp4655909yba; Sun, 12 May 2019 18:59:41 -0700 (PDT) X-Google-Smtp-Source: APXvYqyJ6tsAuZ6no2LB1h2iTX1gz1Ex8+Sw0I4uWW4piY3pvqFDaFPga5naJYHREpNsgSVqK0sA X-Received: by 2002:a17:902:bc85:: with SMTP id bb5mr27814337plb.310.1557712781825; Sun, 12 May 2019 18:59:41 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1557712781; cv=none; d=google.com; s=arc-20160816; b=0eRdPeOkjPEYwympf9UDH0O2iVtcT93y9pT+kemJSZD3zrKv1iWBuKgePWUoMW2XRc Qq4jRiCrMDjPDQNGrTxPIHq8gxQ15SyM/8JiI5YrtzYLAoNKqlJfK4pmw9TxZBrQRygR aqfpPMA/4w2Snj2dUy6NNFqJI9q9S/MREj71ClWcX/k6g2c5eYuwKw0axnbaimOpvAe2 a113mhafJlTHwwbQFkJaQeD+lw0B+I1kdYgfWc2fEiGqErbCdnKWeFAYk8j8B+Zjt7m0 I0N5MHUrSKiCfEOlZVliRzGzgNz4oAG9+ifWvKNd46vh0ubuMjBpYrD4+LltVVmq0u/4 7mqA== 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=AFwJjsoI2KEo93zSpCsPKaldMzn5Y0VykcAR/gk91yw=; b=U6XewvXB6PlaYVHJvwTBFqXIlZui1WQIleG8CCAti7BD0rkwaYSxcnge8i/MMFzfZ5 1GMW8Hqdww6z6cIXjrpNyPemZ+DqPSS9kpGQ9FT3bjSrBVxJQ1MEWhMrPmjTod+JiWqF flm2JLQx0AN2+6mQ1bLGJr4s2xML4JBu1SFoiP6BheHMJyAlaqiKSFXkm1+VdsHzpdvv OP9ZlRDeqVdJK5s1jgUvHjVeFRqB/TPUQLlYn2O0SjKD0KE79i8yXfHinODEJd8JA9o3 TXaceI7GZdrT7R0ddlTf17hyhjH7xyhZgW+Jfhygol+7klfx1EsyTsFGLrdwuZDvHQD7 /96w== 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 f13si16412092pga.385.2019.05.12.18.59.25; Sun, 12 May 2019 18:59:41 -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 S1727331AbfEMBwt (ORCPT + 99 others); Sun, 12 May 2019 21:52:49 -0400 Received: from mx1.redhat.com ([209.132.183.28]:50154 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727054AbfEMBwt (ORCPT ); Sun, 12 May 2019 21:52:49 -0400 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id F08D13082132; Mon, 13 May 2019 01:52:48 +0000 (UTC) Received: from dhcp-128-65.nay.redhat.com (ovpn-12-91.pek2.redhat.com [10.72.12.91]) by smtp.corp.redhat.com (Postfix) with ESMTPS id EFAF05D9D2; Mon, 13 May 2019 01:52:44 +0000 (UTC) Date: Mon, 13 May 2019 09:52:41 +0800 From: Dave Young To: Kairui Song Cc: linux-kernel@vger.kernel.org, Rahul Lakkireddy , Ganesh Goudar , "David S . Miller" , Eric Biederman , Alexey Dobriyan , Andrew Morton , "kexec@lists.infradead.org" Subject: Re: [RFC PATCH] vmcore: Add a kernel cmdline device_dump_limit Message-ID: <20190513015241.GA8515@dhcp-128-65.nay.redhat.com> References: <20190510102051.25647-1-kasong@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190510102051.25647-1-kasong@redhat.com> User-Agent: Mutt/1.11.3 (2019-02-01) X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.42]); Mon, 13 May 2019 01:52:49 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 05/10/19 at 06:20pm, Kairui Song wrote: > Device dump allow drivers to add device related dump data to vmcore as > they want. 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 device_dump_limit= kernel parameter, and set the > default limit to 0, so device dump is not enabled unless user specify > the accetable maxiam memory usage for device dump data. In this way user > will also have the chance to adjust the kdump reserved memory > accordingly. The device dump is only affective in kdump 2nd kernel, so add the limitation seems not useful. One is hard to know the correct size unless one does some crash test. If one did the test and want to eanble the device dump he needs increase crashkernel= size in 1st kernel and add the limit param in 2nd kernel. So a global on/off param sounds easier and better, something like vmcore_device_dump=on (default is off) > > Signed-off-by: Kairui Song > --- > fs/proc/vmcore.c | 20 ++++++++++++++++++++ > 1 file changed, 20 insertions(+) > > diff --git a/fs/proc/vmcore.c b/fs/proc/vmcore.c > index 3fe90443c1bb..e28695ef2439 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); > + > +/* Device Dump Limit */ > +static size_t vmcoredd_limit; > #endif /* CONFIG_PROC_VMCORE_DEVICE_DUMP */ > > /* Device Dump Size */ > @@ -1465,6 +1468,11 @@ int vmcore_add_device_dump(struct vmcoredd_data *data) > data_size = roundup(sizeof(struct vmcoredd_header) + data->size, > PAGE_SIZE); > > + if (vmcoredd_orig_sz + data_size >= vmcoredd_limit) { > + ret = -ENOMEM; > + goto out_err; > + } > + > /* Allocate buffer for driver's to write their dumps */ > buf = vmcore_alloc_buf(data_size); > if (!buf) { > @@ -1502,6 +1510,18 @@ int vmcore_add_device_dump(struct vmcoredd_data *data) > return ret; > } > EXPORT_SYMBOL(vmcore_add_device_dump); > + > +static int __init parse_vmcoredd_limit(char *arg) > +{ > + char *end; > + > + if (!arg) > + return -EINVAL; > + vmcoredd_limit = memparse(arg, &end); > + return end > arg ? 0 : -EINVAL; > + > +} > +__setup("device_dump_limit=", parse_vmcoredd_limit); > #endif /* CONFIG_PROC_VMCORE_DEVICE_DUMP */ > > /* Free all dumps in vmcore device dump list */ > -- > 2.20.1 > Thanks Dave