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:	Mon, 12 Mar 2012 22:31:21 -0700
From:	Yinghai Lu <yinghai@...nel.org>
To:	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>
Cc:	Vivek Goyal <vgoyal@...hat.com>, linux-kernel@...r.kernel.org
Subject: Re: crash dump memory reservation regression

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