linux-kernel - Re: [Patch 0/7] Implement crashkernel=auto

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: <m1iqh1nxv3.fsf@fess.ebiederm.org>
Date:	Thu, 06 Aug 2009 01:35:28 -0700
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	Amerigo Wang <amwang@...hat.com>
Cc:	Neil Horman <nhorman@...hat.com>, linux-kernel@...r.kernel.org,
	tony.luck@...el.com, linux-ia64@...r.kernel.org,
	akpm@...ux-foundation.org, Ingo Molnar <mingo@...e.hu>,
	Anton Vorontsov <avorontsov@...mvista.com>,
	Andi Kleen <andi@...stfloor.org>
Subject: Re: [Patch 0/7] Implement crashkernel=auto

Amerigo Wang <amwang@...hat.com> writes:

> The kernel doesn't have to reserve the exact amount of memory that a kexec
> kernel will use, it just finds a big enough size for all cases which already
> assumes the physical memory is large enough.

>> I think if what you were proposing was part of some coherent story for
>> a complete implementation I would consider it more.  Instead this just
>> appears to be a reaction to how frustrating the user space
>> implementation is, and fixing things in the kernel instead of in user
>> space.
>>   
>
> Yes, exactly, in fact I am doing another part which will allow us to take back
> of the reserved memory at run-time.

Alright. Let's look at that.

I would make the restriction you can't resize the area while a kexec
on panic image is loaded, and growing the area would not be a
realistic option.

If crash_kernel=auto happens in the context of being able to shrink
the area from user space the definition is simple.  We reserve as much
memory as we think we can without affecting performance, stability,
reliability.

We can use an initial approximation of perhaps 1/32nd of low memory
(aka directly mapped memory), and I don't see a point in making the
code arch dependent at all.  We should run the size approximation past
the folks on linux-mm as they are more likely to know how much memory
reduction we can tolerate without problems.

We can then plan on user space saying hey that is more than I need:
shrink that, and load the kexec on panic kernel.

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