linux-kernel - Re: [RFC/PATCH] SLQB: Mark the allocator as broken PowerPC and S390

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:	Thu, 17 Sep 2009 14:13:39 +0300
From:	Pekka Enberg <penberg@...helsinki.fi>
To:	Mel Gorman <mel@....ul.ie>
Cc:	linux-kernel@...r.kernel.org, akpm@...ux-foundation.org,
	cl@...ux-foundation.org, heiko.carstens@...ibm.com, mingo@...e.hu,
	npiggin@...e.de, sachinp@...ibm.com
Subject: Re: [RFC/PATCH] SLQB: Mark the allocator as broken PowerPC and S390

Hi Mel,

On Thu, 2009-09-17 at 11:57 +0100, Mel Gorman wrote:
> The danger is that this isn't a PPC or s390 bug then as such, but a bug where
> there are either memoryless nodes or when node 0 is memoryless.  Hence, there
> is no guarantee that your Kconfig option will catch all instances where this
> bug triggers.  Granted, the configuration is most likely a PPC machine :)

Yes, I suggested making SLQB depend on !NUMA to Nick but he didn't like
that as it's known to be good on x86 NUMA configs.

On Thu, 2009-09-17 at 11:08 +0100, Mel Gorman wrote:
> > > The danger is if SLQB is being silently disabled, it'll never be noticed
> > > or debugged :/
> > 
> > Maybe, but that's not an excuse to push something that's known to break. 

On Thu, 2009-09-17 at 11:57 +0100, Mel Gorman wrote:
> Wow, this is from back in May! Lame.

Heh, my (lame) excuse is lack of relevant hardware.... ;-)

On Thu, 2009-09-17 at 11:57 +0100, Mel Gorman wrote:
> I'm against silently disabling it. Memoryless nodes are extremely rare but
> bugs crop up there occasionally and take a long time to catch and squash. SLQB
> breaking there is not going to cause widespread damage but force a fix to
> be developed by the people with access to the affected machines.

Hey, if someone sends me fix for the bug well before the merge window
closes, that would be great! But there's no way we're adding new core
kernel code that's _known_ to break peoples configs, at least not
through slab.git. If disabling SLQB is not acceptable and we're unable
to fix things, we'll just have to skip this release cycle.

On Thu, 2009-09-17 at 11:57 +0100, Mel Gorman wrote:
> Total aside, does anybody know handily if fake NUMA support allows the
> creation of memoryless nodes help reproducing problems like this? If I can't
> get a real machine, that'll be the approach I'll be trying.

That would be useful, yes.

			Pekka

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