Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp1932419yba; Fri, 10 May 2019 03:36:33 -0700 (PDT) X-Google-Smtp-Source: APXvYqwLTfohofZ3NekNiszNKXXKmLtECuMcR9yqP1GwggAnrrdeRdbDpBgCIHIFUCA0UEyFs/G+ X-Received: by 2002:a63:5421:: with SMTP id i33mr12665134pgb.257.1557484593304; Fri, 10 May 2019 03:36:33 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1557484593; cv=none; d=google.com; s=arc-20160816; b=gdsMBjpwc41bBOyCD19kMZGD+xSDaCVKOra70fqNlVQhXOjW7N3TYkAGqGogpfeZfw xgAtCqxzwIpj5KgAZ3Zl1QKczczalWOghWxXhmvWb4xKtCD+E4rk4RqCGDAQz5AKqKUZ nvhyv8PJNTmqsv5ODd9JfCorJYxkAqE15xowemuDZ3nEWl0asD9Qu5xA5oZjWi9Ie8ck fBHaBYm4KkTKlEBEY9kz6V46XS93ffvRSF4VZiIkIZm7ZJjHrWmBfJ0VAuR0EcmlxF2W lTrrH3v5AFrEr6vL1rLcoHLWJcIPhJCobxqJL/xgAuk3utcn9khr0YP42G3IMqfrqk6t YbgA== 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=jB82dZmUImybIM0NIHIOaQyKfd4OS8rkOpfST8202lY=; b=HlhL0RBrcss+rDOTDZoQvLMozbI5eSqm35cUAsbbhk2JHaXL7KiCMdFLKEp/wcCMrl JUMp+4nJ3IMifXApCnuX15827TCfzvQkA1thjpdyZCOtJ4ZkBgbMrvgyQ+RYEap1g728 ITtKSE3q2pU4ZikjzC38Ua5pBk9361DygNo47WKs8Gzx2F/UdOhQ3M5nDJZet2hxJGBj IY+6XUbVs8FanIicUsByKocQYbcUW0BjPqf35EuX1w54PonL0ifjfWAd9zJX3kktJ3Fe uMbwRBT6T2kVoDVe+VQKgRAA+uTVbwoDGdtWA+UxW6M+6bsRdf1xCYq2aJ/SP7MQCnP5 T/VQ== 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 z184si7435788pgb.409.2019.05.10.03.36.16; Fri, 10 May 2019 03:36: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 S1727565AbfEJKfK (ORCPT + 99 others); Fri, 10 May 2019 06:35:10 -0400 Received: from mx1.redhat.com ([209.132.183.28]:48500 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727251AbfEJKfJ (ORCPT ); Fri, 10 May 2019 06:35:09 -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 3467A85376; Fri, 10 May 2019 10:35:09 +0000 (UTC) Received: from kasong-rh-laptop.pek2.redhat.com (wlc-trust-190.pek2.redhat.com [10.72.3.190]) by smtp.corp.redhat.com (Postfix) with ESMTP id 9E547600C7; Fri, 10 May 2019 10:35:03 +0000 (UTC) From: Kairui Song To: linux-kernel@vger.kernel.org Cc: Rahul Lakkireddy , Ganesh Goudar , "David S . Miller" , Eric Biederman , Alexey Dobriyan , Andrew Morton , Dave Young , "kexec@lists.infradead.org" , Kairui Song Subject: [RFC PATCH] vmcore: Add a kernel cmdline device_dump_limit Date: Fri, 10 May 2019 18:20:51 +0800 Message-Id: <20190510102051.25647-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.25]); Fri, 10 May 2019 10:35:09 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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. 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