linux-kernel - Re: kdump broken on 2.6.37-rc4

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: <4D0AF23D.4010909@zytor.com>
Date:	Thu, 16 Dec 2010 21:16:45 -0800
From:	"H. Peter Anvin" <hpa@...or.com>
To:	Yinghai Lu <yinghai@...nel.org>
CC:	Vivek Goyal <vgoyal@...hat.com>,
	Stanislaw Gruszka <sgruszka@...hat.com>,
	Ingo Molnar <mingo@...e.hu>,
	Thomas Gleixner <tglx@...utronix.de>,
	Maxim Uvarov <muvarov@...il.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Neil Horman <nhorman@...hat.com>
Subject: Re: kdump broken on 2.6.37-rc4

On 12/16/2010 08:46 PM, Yinghai Lu wrote:
>>
>> Second, this patch only applies if "crashkernel=" is not specified, so
>> it doesn't even apply to your situation.
> current code:
>         /* 0 means: find the address automatically */
>         if (crash_base <= 0) {
>                 const unsigned long long alignment = 16<<20;    /* 16M */
> 
>                 /*
>                  *  kexec want bzImage is below DEFAULT_BZIMAGE_ADDR_MAX
>                  */
>                 crash_base = memblock_find_in_range(alignment,
>                                DEFAULT_BZIMAGE_ADDR_MAX, crash_size, alignment);
> 
>                 if (crash_base == MEMBLOCK_ERROR) {
>                         pr_info("crashkernel reservation failed - No suitable area found.\n");
>                         return;
>                 }
>         } else {
>                 unsigned long long start;
> 
>                 start = memblock_find_in_range(crash_base,
>                                  crash_base + crash_size, crash_size, 1<<20);
>                 if (start != crash_base) {
>                         pr_info("crashkernel reservation failed - memory is in use.\n");
>                         return;
>                 }
>         }
> 
> first branch : will take only crash_size.
> second branch : will need to specify crash_base and crash_size.
> 
>>
>> Third, if you have to specify "crashkernel=" that means that there is
>> yet another problem here that should be fixed.
> 
> no, every kdump need to specify crashkernel=128M or more.
> 

Oh, you're referring to crashkernel size.  Okay, this is somewhat
different.  However, the margin is just too small on 64 bits, then.  How
far up can we actually get away with on 64 bits currently?  4 GiB?

	-hpa

-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.

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