Received: by 2002:a25:86ce:0:0:0:0:0 with SMTP id y14csp1611242ybm; Thu, 23 May 2019 04:06:34 -0700 (PDT) X-Google-Smtp-Source: APXvYqyOj/FElEDx3sLeerQbnICVztLu0tMptT7sK6R+QRAuZfsiXhwmzhkfntC7NGy9ur81IBl9 X-Received: by 2002:a17:902:9a84:: with SMTP id w4mr35720689plp.241.1558609594071; Thu, 23 May 2019 04:06:34 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1558609594; cv=none; d=google.com; s=arc-20160816; b=GX3Xhf/JBy4dQY6jwc+2O6TP5/JJgdwp9thWO6OFhqT0QqvddymWVHrKriNJtxUieL TLngXxUTnVMTYxRXoqbZvpb325Pr7zjWMdqbQKLfeHVj5iyeFwfrwEQLAIRHdWmpSUvf OG8Nj4Hmuf/dYQ2dJSE0nYpu2AkSdsTRvpNwh3eEwLlB1IVvGVjRYWtkqCb3d37w0GDO BEdv1npYRs0gl6G34Fs9bOoXVQmpueF85Jwm+TtgcglyNf7kaAz9S+g4SiVLvQ8TgQkp TfC5sFvbvf/b/ZkULetzaxi+VhZ345zFmzAkV37shM85Kdv+Q/++eQfwX8CL3BZtKswr w2pw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version; bh=bszh6zWvpIHD18LEdDJozbrleTCn7t9j7iqoQX16fGM=; b=BpwJTIPUAnfvpQvXtvZ7TLPOL4ef0hB0TNwd6fEkmeexYqrFpKP+FD8H7ylXLVpyDJ O226IltZ9aU0uOhFcyG0dcqhQZhMAXBLNcoTWytx5xalcp1W99vU2YyMGzAIf0c8DNen vj3FBwuWtRYgPKIDUgMDgk1svTVHeSt45elX50AQTHF44YeiWbkCqNPJ3K2wB2+EnIX8 5lSvk14du+J+cliJIzBddxZOFvYI0UyYnBcI+7lb1n5fLMDATABGnx92Fs/hcXzSKUCz 4pskZhxOVRw//7eNVVJSi61U4QLwMH6HZeFC3BlDGG9lkR7xUCtVO7aM2AU10W7EITB0 wZdg== 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 ay3si26869849plb.298.2019.05.23.04.06.18; Thu, 23 May 2019 04:06:34 -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 S1730318AbfEWLE6 (ORCPT + 99 others); Thu, 23 May 2019 07:04:58 -0400 Received: from mail-it1-f193.google.com ([209.85.166.193]:55089 "EHLO mail-it1-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726429AbfEWLE6 (ORCPT ); Thu, 23 May 2019 07:04:58 -0400 Received: by mail-it1-f193.google.com with SMTP id h20so8891882itk.4 for ; Thu, 23 May 2019 04:04:57 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=bszh6zWvpIHD18LEdDJozbrleTCn7t9j7iqoQX16fGM=; b=RD08U9sC6ZYEHrUzMFD6/ept4W9FyhEN3Lm8Jzb61IKq9RLIC05QlTgbHnkrc1HfKp y161BMqwOJDpwXWvXxlCrZ/flAA5VS31End9o8WTyahHtGwlI3ltlZKUNWMDCdZZHcuK ICedpJn+6hlVZHVZnOgJe+ZoWYH9h8xKYkhlUBdgdYRTEwUgzMjKvl6t/ZPPF/3UmtoM GEKJ50uGEdFw6VbTjGwo/lhPthfAUHVbmPH3o2YkA24dYbpcEpnl+hyFtI0D/sl4aPLM 9gxStzKR3BSozqrUgSjtyGEOvlHISPIYl0OjcKINZVKC4q2uOvcfBM77TmtqWWk5hzAn SiPg== X-Gm-Message-State: APjAAAWxpmyEbe7jEz5HlnnxtgfDBQ8g68FlFtLTrrbJc9iDUo0nvqjo cjfepVaaQVmvRkhobF08Su0jlYiHJM1dm6v2RrODKw== X-Received: by 2002:a24:6cd5:: with SMTP id w204mr12287305itb.12.1558609497196; Thu, 23 May 2019 04:04:57 -0700 (PDT) MIME-Version: 1.0 References: <20190520061834.32231-1-kasong@redhat.com> <0c0fb7af-f386-bde1-46f6-1afa29782243@redhat.com> In-Reply-To: <0c0fb7af-f386-bde1-46f6-1afa29782243@redhat.com> From: Kairui Song Date: Thu, 23 May 2019 19:04:36 +0800 Message-ID: Subject: Re: [PATCH v2] vmcore: Add a kernel cmdline vmcore_device_dump To: Bhupesh Sharma Cc: Linux Kernel Mailing List , Rahul Lakkireddy , "David S . Miller" , Eric Biederman , Alexey Dobriyan , Andrew Morton , Dave Young , "kexec@lists.infradead.org" Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, May 23, 2019 at 2:44 AM Bhupesh Sharma wrote: > > 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. > Good suggestion! I'll update in V3. -- Best Regards, Kairui Song