linux-kernel - Re: [PATCH -next] Documentation: Improve crashkernel= description

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: <20110207143346.GB7437@redhat.com>
Date:	Mon, 7 Feb 2011 09:33:46 -0500
From:	Vivek Goyal <vgoyal@...hat.com>
To:	Simon Horman <horms@...ge.net.au>
Cc:	Rob Landley <rlandley@...allels.com>, linux-doc@...r.kernel.org,
	kexec@...ts.infradead.org, LKML <linux-kernel@...r.kernel.org>,
	"Ahmed S. Darwish" <darwish.07@...il.com>,
	Haren Myneni <hbabu@...ibm.com>,
	Randy Dunlap <rdunlap@...otime.net>,
	Eric Biederman <ebiederm@...ssion.com>,
	"H. Peter Anvin" <hpa@...or.com>
Subject: Re: [PATCH -next] Documentation: Improve crashkernel= description

On Mon, Feb 07, 2011 at 11:42:38AM +0900, Simon Horman wrote:
> On Sun, Feb 06, 2011 at 08:25:20PM -0600, Rob Landley wrote:
> > On 02/06/2011 03:57 PM, Simon Horman wrote:
> > > On Sun, Feb 06, 2011 at 05:41:08PM +0200, Ahmed S. Darwish wrote:
> > >> (Also applicable over 2.6.38-rc3)
> > >>
> > >> Had to explore two C code files to make sense of the 'crashkernel='
> > >> kernel parameter values.  Improve the situation.
> > >>
> > >> Signed-off-by: Ahmed S. Darwish <darwish.07@...il.com>
> > >> ---
> > >>
> > >> diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt
> > >> index 89835a4..8f26b42 100644
> > >> --- a/Documentation/kernel-parameters.txt
> > >> +++ b/Documentation/kernel-parameters.txt
> > >> @@ -545,9 +545,12 @@ and is between 256 and 4096 characters. It is defined in the file
> > >>  			Format:
> > >>  			<first_slot>,<last_slot>,<port>,<enum_bit>[,<debug>]
> > >>  
> > >> -	crashkernel=nn[KMG]@ss[KMG]
> > >> -			[KNL] Reserve a chunk of physical memory to
> > >> -			hold a kernel to switch to with kexec on panic.
> > >> +	crashkernel=size[KMG][@offset[KMG]]
> > >> +			[KNL] Using kexec, Linux can switch to a 'crash kernel'
> > >> +			upon panic. This parameter reserves the physical
> > >> +			memory region [offset, offset + size] for that kernel
> > >> +			image. If the '@...set' part was ignored, Linux finds
> > >> +			a suitable crash image start address automatically.
> > > 
> > > I think this would be further improved as:
> > > 
> > > 			... If '@...set' is omitted then a suitable
> > > 			offset is selected automatically.
> > 
> > Suitable offset as in parses a known image type (ELF, bzImage, etc) to
> > find the start address?  Or just assumes the entry point and load
> > address are the same?
> 
> As in it finds a large enough area of contiguous free memory.
> I believe that originally it searched from the bottom of memory,
> it may be slightly smarter now.

Now it has been changed to search from top of the memory (atleast for x86) and
that caused few troubles. On 32bit it searches for memory under 512MB and
on x86_64, it searches for memory under 896MB.

Though hpa had suggested to enhance the command line syntax such that a
user specifies the upper bound on memory. Something like crashkernel=x < y.
So reserve X amount of memory below y MB. It boils down to same thing
that somebody has to know that what is the maximum physical memory
locaton kernel can boot from.

I think it is dependent on kernel as well as dependent on kexec-tools. I
am wondering if it is possible to make this info part of bzImage protocol
where kernel tells bootloader the maximum physical memory kernel can be
loaded at. I think this is off topic in the context of this patch, just
a thought...

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