linux-kernel - Re: [RESEND][PATCH v2 2/2] powerpc/fadump: parse fadump reserve memory size based on memory range

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, 08 Aug 2016 18:56:13 +1000
From:	Michael Ellerman <mpe@...erman.id.au>
To:	Hari Bathini <hbathini@...ux.vnet.ibm.com>, rusty@...tcorp.com.au,
	ebiederm@...ssion.com, vgoyal@...hat.com,
	linuxppc-dev <linuxppc-dev@...abs.org>
Cc:	Mahesh J Salgaonkar <mahesh@...ux.vnet.ibm.com>,
	kexec@...ts.infradead.org, lkml <linux-kernel@...r.kernel.org>,
	Ananth N Mavinakayanahalli <ananth@...ibm.com>
Subject: Re: [RESEND][PATCH v2 2/2] powerpc/fadump: parse fadump reserve memory size based on memory range

Hari Bathini <hbathini@...ux.vnet.ibm.com> writes:
> On Friday 05 August 2016 12:23 AM, Hari Bathini wrote:
>> On Thursday 04 August 2016 03:15 PM, Michael Ellerman wrote:
>>> The code already knows how to reserve 5% based on the size of the 
>>> machine's
>>> memory, as long as no commandline parameter is passed. So why can't we
>>> just use that logic?
>>
>> That is the default value reserved but not a good enough value for
>> every case. It is a bit difficult to come up with a robust formula
>> that works for every case as new kernel changes could make the
>> values obsolete. But it won't be all that difficult to find values that
>> work for different memory ranges for a given kernel version.
>> Passing that as range based input with "fadump_reserve_mem"
>> parameter would work for every memory configuration on a
>> given system, which is what this patch is trying to provide..
>
> You want me to add this to the changelog on respin?

I'm not really convinced.

Distros are going to want to specify a fixed set of values for different
memory sizes, at least that's what I've seen in the past with kdump. So
I don't see why we can't just do that in the kernel with a formula based
on memory size, and maybe some other information.

Maybe the formula is more complicated than 5% of RAM, but it shouldn't
be *that* much more complicated.

cheers