linux-kernel - Re: [PATCH] kexec: use Crash kernel for Crash kernel low

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:	Mon, 01 Apr 2013 13:47:58 -0700
From:	"H. Peter Anvin" <hpa@...or.com>
To:	Vivek Goyal <vgoyal@...hat.com>
CC:	Thomas Gleixner <tglx@...utronix.de>, Ingo Molnar <mingo@...e.hu>,
	WANG Chao <chaowang@...hat.com>,
	"Eric W. Biederman" <ebiederm@...ssion.com>,
	linux-kernel@...r.kernel.org, Yinghai Lu <yinghai@...nel.org>
Subject: Re: [PATCH] kexec: use Crash kernel for Crash kernel low

On 04/01/2013 12:26 PM, Vivek Goyal wrote:
> 
> Hi Peter,
> 
> I agree that this dependency on crashkernel is creating lots of problems
> and there should be a better way to manage it.
> 
> Sorry, but I did not fully understand your suggestion on how to handle the
> problem. IIUC, you are suggesting that kexec-tools has the memory
> requirements and when that package installs, it should automatically
> update boot loader command line to communicate that requirement to kernel?
> Or are you suggesting something else entirely.

Yes.  Or rather, kexec-tools should provice a script or utility to
calculate the proper options and let a distribution-specific script add
it to the bootloader configuration.

> Where to reserve is not entirely tied to kexec-tools version. It also
> depends on the environment and run time user options. 

Yes, and the user cannot reasonably be expected to know what that should
be.  You're basically telling the user "guess and pray".

> For example kernel image being loaded and entry point selected. So if one
> decides to load take 32bit entry point of bzImage then memory has to be
> reserved in first 4G (despite the fact that kexec-tools is able to load 64bit
> bzImage and handle higher reserved ranges).
> 
> Also whether to reserve memory for software iotlb will depend on whether
> we have chosen to enable iommu in second kernel or not.
> 
> So sorting out all the memory reservation requirements based on
> kexec-tools version and during installation time alone might not work.
> 
> To make user's life easier, we can probably modify "kdump" service and
> provide another option which can calculate the right crashkernel= command
> line option based on user selected option and system environment and
> display it to user (or possibly propogate to bootloader command line and
> system is rebooted).

Yes, I think we need to so something.

> All this will only address the issue of where to reserve memory. It will
> still not solve the issue of how much memory to reserve. We have no way
> to know. It is all heuristics.

At least heuristics in a script is better than telling the user "guess
and pray".

> crashkernel=<size>,<option>,<option>.. and crashkernel=800M,high sound
> good to me. 
> 
> So atleast for 3.9 kernel, shall we hide new semantics behind
> crashkernel=XM,high and by default crashkernel=XM tries to emulate
> crashkernel=XM,low to retain backward compatibility?

Yes, I suspect so.

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