linux-kernel - Re: [RFC PATCH v5 1/9] 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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <4ECF988A.1090203@linux.vnet.ibm.com>
Date:	Fri, 25 Nov 2011 19:00:50 +0530
From:	"Mahesh J. Salgaonkar" <mahesh@...ux.vnet.ibm.com>
To:	linux-kernel@...r.kernel.org
Cc:	linux-kernel@...r.kernel.org, linuxppc-dev@...abs.org
Subject: Re: [RFC PATCH v5 1/9] fadump: Add documentation for firmware-assisted
 dump.

On 11/25/2011 04:04 AM, Paul Mackerras wrote:
> On Tue, Nov 15, 2011 at 08:43:34PM +0530, Mahesh J Salgaonkar wrote:
>> 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.
> 
> In general we don't want the changes between successive versions in
> the patch description; this information should go below the "---"
> line.  The patch description should describe how the patch is now and
> give any information that will be useful to someone looking at the
> resulting git commit later on, but it doesn't need to tell us about
> previous versions of the patch that will never appear in the git
> history.

Sure will do that.

> 
>> +-- Once the dump is copied out, the memory that held the dump
>> +   is immediately available to the running kernel. A further
>> +   reboot isn't required.
> 
> I have a general worry about the system making allocations that are
> intended to be node-local while it is running with restricted memory
> (i.e. after the crash and reboot and before the dump has been written
> out and the dump memory freed).  Those allocations will probably all
> come from one node and thus won't necessarily be on the desired node.
> So, for very large systems with significant NUMA characteristics, it
> may be desirable (though not required) to reboot after taking the
> dump.

I have been working on trying to integrate FADUMP with the kdump
infrastructure on distros, which will modify the existing kernel initrd
to capture the vmcore and release the memory at the very early stage
before the switch_root.

However, by default FADUMP will also reboot after capturing vmcore
unless user specifies 'noreboot' option through kdump configuration file.

> 
> What happens about the NUMA information in the kernel -- all the
> memory sections, etc.?  Do they get set up as normal even though the
> second kernel is booting with only a small amount of memory initially?
> 

In FADUMP case, the booting of second kernel after crash is equivalent
to normal kernel bootup and it boots with the knowledge of entire system
RAM with NUMA information. The memblock structure does contain map for
entire system RAM. We just reserve the memory above the bootmem at the
very early stage in the second kernel, so that it remains untouched.

Thanks,
-Mahesh.

--
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/