linux-kernel - Re: kdump info request

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>] [day] [month] [year] [list]

Message-ID: <20071003041545.GA5343@in.ibm.com>
Date:	Wed, 3 Oct 2007 09:45:45 +0530
From:	Vivek Goyal <vgoyal@...ibm.com>
To:	Randy Dunlap <rdunlap@...otime.net>
Cc:	"Mukker, Atul" <Atul.Mukker@....com>,
	"Moore, Eric" <Eric.Moore@....com>,
	Kexec Mailing List <kexec@...ts.infradead.org>,
	linux kernel mailing list <linux-kernel@...r.kernel.org>,
	balbir@...ibm.com, Pavel Machek <pavel@....cz>
Subject: Re: kdump info request

On Mon, Oct 01, 2007 at 09:31:45AM -0700, Randy Dunlap wrote:
> On Mon, 1 Oct 2007 09:35:04 -0600 Mukker, Atul wrote:
> 
> > Thanks for the information and the effort.
> > 
> > We need to support all currently shipping products with kdump support
> > available (read Red Hat and SuSE) so sooner it makes into to the
> > upstream kernel the better it is.
> > 
> > So, today there is no alternative way to find out if the driver is being
> > loaded under kdump restrictive environment?
> > 
> > Thanks
> > -Atul
> 
> I'm not the right person to answer that, but going forward, it would
> be nice to have that information and it would be good to do correctly.
> 
> I think that scanning <saved_command_line> is not actually the good/right
> way to do this.  It should just be a flag somewhere, and the flag should
> be available in all (future) kernels (and likely easily backportable
> as well, if that matters), meaning those built without kdump support.
> 
> But it's still up to the kexec developers...
> 
> 

Hi Atul/Randy,

[CCing to LKML]

Thinking more about it, looks like scanning command line is not a very good
idea.

I think we should instead look for if total available RAM in the system and
then let driver make a decision about how much memory to allocate. Pavel
already suggested it on LKML and I like the idea.

This is more generic and can be applied to kdump, kexec based hibernation and
all the future users of kexec on panic infrstrcuture which will boot a 
second kernel in restricted amount of RAM.

I am not sure what's the best way to determine the total RAM in the system
in arch independent manner. Some VM guys can tell it better. One of the ways
could be to parse /proc/iomem, the way kexec-tools does. Balbir mentioned
that traverse through the nodes and sum up present_pages. 

Any suggestions, what's the best way to determine total amount of RAM
in the system in kernel?

Right now this seems to be one odd case so this code can be inside module.
If there are more users of it then we can probably create a flag inside
kernel and export it.

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/