linux-kernel - [RFC PATCH 0/3] Hatchet job for SLQB on memoryless configurations

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-next>] [day] [month] [year] [list]

Date:	Fri, 18 Sep 2009 20:34:08 +0100
From:	Mel Gorman <mel@....ul.ie>
To:	Nick Piggin <npiggin@...e.de>,
	Pekka Enberg <penberg@...helsinki.fi>,
	Christoph Lameter <cl@...ux-foundation.org>
Cc:	heiko.carstens@...ibm.com, sachinp@...ibm.com,
	linux-kernel@...r.kernel.org, linux-mm@...ck.org,
	Mel Gorman <mel@....ul.ie>
Subject: [RFC PATCH 0/3] Hatchet job for SLQB on memoryless configurations

Currently SLQB is not allowed to be configured on PPC and S390 machines as
CPUs can belong to memoryless nodes. SLQB does not deal with this very well
and crashes reliably.

This patch partially fixes the problem on at least one machine and allows
SLQB to boot although I'm not sure if it's actually stable. It's doubtful
this is the solution even in the short-term. This is a hatchet job due to
my lack of familiarity with SLQB. While SLQB is handy to get to grips with,
someone more familiar may be able to identify a proper fix faster assuming
this helps point the direction of the real problem.

Patch 1 statically defines some per-node structures instead of using a fun
	hack with DEFINE_PER_CPU. The problem was that the per-node structures
	appeared to be getting corrupted (different values each boot on
	struct fields, particularly the lock), possibly because the active
	node IDs are higher than the highest CPU id. It's not known why
	this is a problem at the moment and could do with further explanation.

Patch 2 noticed that on memoryless nodes, slab objects always gets freed to
	the remote list while the allocation side always looked at the per-cpu
	lists. Lists grew in an unbounded fashion and the machine OOM'd. This
	patch checks if the remote page is being freed to a memoryless node
	and if so, the page is treated as if it's local. This needs further
	thinking from someone familiar with SLQB.

Patch 3 allows SLQB to be configured on PPC and S390 again.

This patchset is not intended for merging. It's to help point out where the
real problems might be so a proper fix can be hashed out.

 init/Kconfig |    1 -
 mm/slqb.c    |   23 +++++++++++++----------
 2 files changed, 13 insertions(+), 11 deletions(-)

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