linux-kernel - sparc64 bootup 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 for Android: free password hash cracker in your pocket

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 29 Apr 2008 23:12:41 -0700 (PDT)
From:	David Miller <davem@...emloft.net>
To:	linux-kernel@...r.kernel.org
CC:	y-goto@...fujitsu.com, akpm@...ux-foundation.org
Subject: sparc64 bootup regression...


This commit causes bootup failures on sparc64:

commit 86f6dae1377523689bd8468fed2f2dd180fc0560
Author: Yasunori Goto <y-goto@...fujitsu.com>
Date:   Mon Apr 28 02:13:33 2008 -0700

    memory hotplug: allocate usemap on the section with pgdat
    
    Usemaps are allocated on the section which has pgdat by this.
    
    Because usemap size is very small, many other sections usemaps are allocated
    on only one page.  If a section has usemap, it can't be removed until removing
    other sections.  This dependency is not desirable for memory removing.
    
    Pgdat has similar feature.  When a section has pgdat area, it must be the last
    section for removing on the node.  So, if section A has pgdat and section B
    has usemap for section A, Both sections can't be removed due to dependency
    each other.
    
    To solve this issue, this patch collects usemap on same section with pgdat.
    If other sections doesn't have any dependency, this section will be able to be
    removed finally.
    
    Signed-off-by: Yasunori Goto <y-goto@...fujitsu.com>
    Cc: Badari Pulavarty <pbadari@...ibm.com>
    Cc: Yinghai Lu <yhlu.kernel@...il.com>
    Cc: Yasunori Goto <y-goto@...fujitsu.com>
    Signed-off-by: Andrew Morton <akpm@...ux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@...ux-foundation.org>

The machine in question has 64 cpus, and 16GB of ram.  CONFIG_NUMA is
not set, and this platform uses sparsemem and vmemmap.

I attach two boot logs.  The first is a successful boot, the second one
is a failing one due to the above commit:

View attachment "good_boot.log" of type "Text/Plain" (20576 bytes)

View attachment "failed_boot.log" of type "Text/Plain" (3882 bytes)