linux-kernel - Re: crash dump memory reservation regression

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:	Wed, 21 Mar 2012 16:17:03 +0800
From:	Dave Young <hidave.darkstar@...il.com>
To:	Yinghai Lu <yinghai@...nel.org>
Cc:	CAI Qian <caiqian@...hat.com>, Takashi Iwai <tiwai@...e.de>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	"H. Peter Anvin" <hpa@...or.com>, Ingo Molnar <mingo@...e.hu>,
	Vivek Goyal <vgoyal@...hat.com>, linux-kernel@...r.kernel.org
Subject: Re: crash dump memory reservation regression

On Tue, Mar 13, 2012 at 1:31 PM, Yinghai Lu <yinghai@...nel.org> wrote:
> On Sun, Mar 11, 2012 at 8:00 PM, CAI Qian <caiqian@...hat.com> wrote:
>> commit 3661ca66a42e306aaf53246fb75aec1ea01be0f0
>> x86, memblock: Fix crashkernel allocation
>>
>> introduced a regression that crashkernel=512M
>> according to bisecting will fail like this,
>>
>> crashkernel reservation failed - No suitable area found.
>> The full dmesg can be found here.
>>
>> http://people.redhat.com/qcai/dmesg.bad
>
> The reason is: we put pagetable for [0,2g) just blow 512M.
>
> Later we have other patches that will put pagetable for [0,2g) just
> below 2g. even at that time we only can access 512M, because we use
> early_ioremap to access page table.
>
> But that good_end part get reverted in following because it cause s4
> resume fail.
>
> So there will be pagetable around just below 512M again. So you have
> no chance to get 512M below 768M.
>
> Solution will be:
> 1.  remove the good_end setting for 64 bit again. and root cause S4 resume.

Takashi, could you check if latest kernel without the good_end patch
below works for you?

> 2.  get page low?
> 3.  fix kdump, and make kdump could take two ranges, one is small
> segment below 512M, other part could be more than 4G.
>
> Thanks
>
> Yinghai
>
>
> commit 8548c84da2f47e71bbbe300f55edb768492575f7
> Author: Takashi Iwai <tiwai@...e.de>
> Date:   Sun Oct 23 23:19:12 2011 +0200
>
>    x86: Fix S4 regression
>
>    Commit 4b239f458 ("x86-64, mm: Put early page table high") causes a S4
>    regression since 2.6.39, namely the machine reboots occasionally at S4
>    resume.  It doesn't happen always, overall rate is about 1/20.  But,
>    like other bugs, once when this happens, it continues to happen.
>
>    This patch fixes the problem by essentially reverting the memory
>    assignment in the older way.
>
>    Signed-off-by: Takashi Iwai <tiwai@...e.de>
>    Cc: <stable@...nel.org>
>    Cc: Rafael J. Wysocki <rjw@...k.pl>
>    Cc: Yinghai Lu <yinghai.lu@...cle.com>
>    [ We'll hopefully find the real fix, but that's too late for 3.1 now ]
>    Signed-off-by: Linus Torvalds <torvalds@...ux-foundation.org>
>
> diff --git a/arch/x86/mm/init.c b/arch/x86/mm/init.c
> index 3032644..87488b9 100644
> --- a/arch/x86/mm/init.c
> +++ b/arch/x86/mm/init.c
> @@ -63,9 +63,8 @@ static void __init find_early_table_space(unsigned
> long end, int use_pse,
>  #ifdef CONFIG_X86_32
>        /* for fixmap */
>        tables += roundup(__end_of_fixed_addresses * sizeof(pte_t), PAGE_SIZE);
> -
> -       good_end = max_pfn_mapped << PAGE_SHIFT;
>  #endif
> +       good_end = max_pfn_mapped << PAGE_SHIFT;
>
>        base = memblock_find_in_range(start, good_end, tables, PAGE_SIZE);
>        if (base == MEMBLOCK_ERROR)
> --
> 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/



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