linux-kernel - Re: SLUB doesn't work with kdump kernel on Cell

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, 8 Aug 2007 22:34:39 +0200
From:	Arnd Bergmann <arnd@...db.de>
To:	Christoph Lameter <clameter@....com>
Cc:	Lucio Correia <ljhc@...ibm.com>, linux-kernel@...r.kernel.org,
	Arnd Bergmann <arndb@...db.de>
Subject: Re: SLUB doesn't work with kdump kernel on Cell

On Wednesday 08 August 2007, Christoph Lameter wrote:
> 
> > I found a problem with SLUB when trying to boot a kdump kernel on a Cell
> > QS20 Blade running Fedora 7, kernel 2.6.22.5. If I use SLAB for the
> > kdump kernel, everything works ok. The fact is that SLUB doesn't find a
> > page frame for allocation in the current node, due to the flag
> > GFP_THISNODE on a call to new_slab, and stops at a BUG_ON on line 1802
> > of slub.c. 
> 
> This is due to the node 1 having only one page. Could you just switch node 
> 1 off?

the kdump kernel needs to access data on the SPUs on node 1. It might be
possible to change that so we can access the SPUs even if there is only
one node, but it's probably not easy to do.

In the future, we also may have configurations where we need to run with
memoryless nodes on a production environment, so it should really just
work.

> > I understand that this flag should not be removed, and that there is a
> > better solution, but it demonstrates the problem. Could you give me some
> > direction on the better way to solve this problem?
> 
> Do not create a node that just has one page in it?
> 
> Or make it truly empty? An empty node will cause GFP_THISNODE to fall back 
> and you then have the same useless control structure allocation as on 
> SLAB.

What makes you assume that there is one page in the node? AFAICS, it
is a CPU-only node already without any pages.

	Arnd <><

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