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]

Date:	Tue, 12 Mar 2013 09:35:41 +0100
From:	Ingo Molnar <mingo@...nel.org>
To:	Vivek Goyal <vgoyal@...hat.com>
Cc:	"H. Peter Anvin" <hpa@...or.com>,
	"Eric W. Biederman" <ebiederm@...ssion.com>,
	Yinghai Lu <yinghai@...nel.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	WANG Chao <chaowang@...hat.com>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] x86, kdump: Set crashkernel_low automatically

* Vivek Goyal <vgoyal@...hat.com> wrote:

> On Mon, Mar 11, 2013 at 01:50:21PM -0700, H. Peter Anvin wrote:
> > On 03/11/2013 01:45 PM, Vivek Goyal wrote:
> > > 
> > > - Now we use dracut generated initramfs and it has been growing in 
> > >   size. Now systemd has been pulled in too.
> > 
> > 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.

The fundamental design problem is this artificial split of the kernel from 
kexec-tools, just to support an arguably exotic feature, which in turn 
then tries to support a complex compatibility matrix - making each variant 
even more super exotic. There's just not enough usage and not enough 
manpower to keep all that tidy ...

If there was tools/kexec/ then many of these constraints and quirks with 
old versions would go away: old kernels would come with old kexec tools, 
new kernels would come with new kexec tools.

Just look at how tools/perf/ is packaged up with new kernels: you 
generally get a new perf with a new kernel version. Alone this eliminates 
a fair bit of support complexity and makes it easier to keep users 
uptodate.

[ kexec tooling could go even farther: if included in the initramfs then
  it could do away with ABI constraints and compatibility expectations
  altogether.

  This is one of the cases where it _does_ make sense: kexec tools and in
  general kernel image analysis is obviously coupled to the kernel's
  current data structures. ]

If this was fixed then kexec could step a whole lot further, not just in 
terms of robustness, but also in terms of feature set - and, ultimately, 
increased usage by users and kernel developers.

Thanks,

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