linux-kernel - Re: [PATCH] x86, kdump: Set crashkernel

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: <513E4771.8070203@zytor.com>
Date:	Mon, 11 Mar 2013 14:06:57 -0700
From:	"H. Peter Anvin" <hpa@...or.com>
To:	Vivek Goyal <vgoyal@...hat.com>
CC:	"Eric W. Biederman" <ebiederm@...ssion.com>,
	Yinghai Lu <yinghai@...nel.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...nel.org>,
	WANG Chao <chaowang@...hat.com>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] x86, kdump: Set crashkernel_low automatically

On 03/11/2013 02:03 PM, Vivek Goyal wrote:
>>
>> And the solution to that isn't obvious?
> 
> Sorry, I did not understand what do you mean by above.
> 
> If you are suggesting that move away from dracut, it does not work
> in practice. Initially we wrote our custom code to generate custom
> initramfs, and we were always lagging in terms of what dump targets
> can be supported and kept on constantly fixing the issues which had
> been taken care of in dracut one way or other. So it was like
> maintaining a duplicate initramfs generation tool.
> 
> So we do not want to use non-standard tools just for kdump. dracut
> generates the initramfs for first kernel and then it should be able
> to for second kernel too.
> 
> Another problem is that other user space component developers, they don't
> know that they are supposed to work with 64MB in total too. Same is true for
> anybody who is writing driver code. 
> 
> And bloated memory usage is detected, after the fact. After that one
> can keep on chasing people, and they say that it is their feature
> requirement. And it is not possible to go and optimize every subsystem
> so that together they can boot and work with 64MB.
> 

Your problem is fundamentally that you are using the wrong tool for the
job, simply because it is expedient to you.  Arguably dracut & co are
the wrong tool for any job given the enormous amount of bloat it
entails, but at least in the normal kernel case it only affects boot
time as it is jettisoned, but in your case it is not.

>>
>>> - makdumpfile needs more memory to dump large machines.
>>>
>>> There are so many places where memory usage is going up and trying
>>> to keep track of all that has been very hard.
>>
>> Seriously, in particular the O(n) memory requirements you may want to
>> think very very hard about.
> 
> Well we now also have a mode in makedumpfile where memory requirement is
> O(1). Just that it takes more cpu and takes much longer to dump. May be it
> can be improved further.
> 
> I am more worried about kernel drivers, and all the user space we need
> to pull in to initramfs to meet more advanced requirements in kdump
> environment.
> 

That seems like a problem you need to deal with, or you will soon be so
bloated that you have substantial performance impact on any system.

	-hpa


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