linux-kernel - Re: [RFC PATCH v4 01/10] fadump: Add documentation for firmware-assisted dump.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20111110104036.GA5145@in.ibm.com>
Date:	Thu, 10 Nov 2011 16:10:36 +0530
From:	Mahesh J Salgaonkar <mahesh@...ux.vnet.ibm.com>
To:	Cong Wang <amwang@...hat.com>
Cc:	linuxppc-dev <linuxppc-dev@...abs.org>,
	Linux Kernel <linux-kernel@...r.kernel.org>,
	Benjamin Herrenschmidt <benh@...nel.crashing.org>,
	Ananth Narayan <ananth@...ibm.com>,
	Milton Miller <miltonm@....com>,
	Haren Myneni <hbabu@...ibm.com>,
	Anton Blanchard <anton@...ba.org>,
	"Eric W. Biederman" <ebiederm@...ssion.com>
Subject: Re: [RFC PATCH v4 01/10] fadump: Add documentation for
 firmware-assisted dump.

On 2011-11-10 17:46:30 Thu, Cong Wang wrote:
> 于 2011年11月07日 17:55, Mahesh J Salgaonkar 写道:
> >From: Mahesh Salgaonkar<mahesh@...ux.vnet.ibm.com>
> >
> >Documentation for firmware-assisted dump. This document is based on the
> >original documentation written for phyp assisted dump by Linas Vepstas
> >and Manish Ahuja, with few changes to reflect the current implementation.
> >
> >Change in v3:
> >- Modified the documentation to reflect introdunction of fadump_registered
> >   sysfs file and few minor changes.
> >
> >Change in v2:
> >- Modified the documentation to reflect the change of fadump_region
> >   file under debugfs filesystem.
> >
> >Signed-off-by: Mahesh Salgaonkar<mahesh@...ux.vnet.ibm.com>
> 
> 
> Please Cc Randy Dunlap <rdunlap@...otime.net> for kernel documentation
> patch.
> 
> I have some inline comments below.
> 

Thanks for your review. I will incorporate all your comments.

<...>
> >+with minor modifications. The kdump script requires following
> >+modifications:
> >+-- During service kdump start if /proc/vmcore entry is not present,
> >+   look for the existence of /sys/kernel/fadump_enabled and read
> >+   value exported by it. If value is set to '0' then fallback to
> >+   existing kexec based kdump. If value is set to '1' then check the
> >+   value exported by /sys/kernel/fadump_registered. If value it set
> >+   to '1' then print success otherwise register for fadump by
> >+   echo'ing 1>  /sys/kernel/fadump_registered file.
> >+
> >+-- During service kdump start if /proc/vmcore entry is present,
> >+   execute the existing routine to save the dump. Once the dump
> >+   is saved, echo 1>  /sys/kernel/fadump_release_mem (if the
> >+   file exists) to release the reserved memory for general use
> >+   and continue without rebooting. At this point the memory
> >+   reservation map will look like as shown in Fig. 1. If the file
> >+   /sys/kernel/fadump_release_mem is not present then follow
> >+   the existing routine to reboot into new kernel.
> >+
> >+-- During service kdump stop echo 0>  /sys/kernel/fadump_registered
> >+   to un-register the fadump.
> >+
> 
> I don't think you need to document kdump script changes in a kernel
> doc.
> 

Agree. I will remove it.

> >+
> >+TODO:
> >+-----
> >+ o Need to come up with the better approach to find out more
> >+   accurate boot memory size that is required for a kernel to
> >+   boot successfully when booted with restricted memory.
> >+ o The fadump implementation introduces a fadump crash info structure
> >+   in the scratch area before the ELF core header. The idea of introducing
> >+   this structure is to pass some important crash info data to the second
> >+   kernel which will help second kernel to populate ELF core header with
> >+   correct data before it gets exported through /proc/vmcore. The current
> >+   design implementation does not address a possibility of introducing
> >+   additional fields (in future) to this structure without affecting
> >+   compatibility. Need to come up with the better approach to address this.
> >+   The possible approaches are:
> >+	1. Introduce version field for version tracking, bump up the version
> >+	whenever a new field is added to the structure in future. The version
> >+	field can be used to find out what fields are valid for the current
> >+	version of the structure.
> >+	2. Reserve the area of predefined size (say PAGE_SIZE) for this
> >+	structure and have unused area as reserved (initialized to zero)
> >+	for future field additions.
> >+   The advantage of approach 1 over 2 is we don't need to reserve extra space.
> >+---
> 
> Why do we keep TODO in this doc?
> 

I see most of the kernel doc do contain TODO, hence I added it here.

Thanks,
-Mahesh.

-- 
Mahesh J Salgaonkar

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/