linux-kernel - Re: [PATCH] nommu: fix kobjsize() for SLOB and SLUB

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]

Message-ID: <20080601082249.GB25429@linux-sh.org>
Date:	Sun, 1 Jun 2008 17:22:49 +0900
From:	Paul Mundt <lethal@...ux-sh.org>
To:	Pekka Enberg <penberg@...helsinki.fi>
Cc:	David Howells <dhowells@...hat.com>,
	Christoph Lameter <clameter@....com>,
	LKML <linux-kernel@...r.kernel.org>, cooloney@...nel.org,
	akpm@...ux-foundation.org, mpm@...enic.com
Subject: Re: [PATCH] nommu: fix kobjsize() for SLOB and SLUB

On Sun, Jun 01, 2008 at 10:58:34AM +0300, Pekka Enberg wrote:
> Paul Mundt wrote:
> >Not until the page->index bits are killed, otherwise you aren't fixing
> >anything. SLOB on nommu with those page->index tests will automatically
> >oops today, before or after your patches. Until that's resolved, there's
> >no point in pretending like kobjsize() has been "fixed". As no one has
> >come up with a valid reason for those tests existing in the first place,
> >simply having your patches and killing the BUG_ON()'s seems ok.
> 
> Sorry if I'm starting to sound like a broken record, but can you explain 
> why removing the ->index bits are safe? I mean, if removing them is 
> really okay, that means we don't hit that code path with SLAB at all?
> 
I thought I already had several times, but I'll attempt to summarize again..

I would expect the only reason those BUG_ON()'s haven't been triggered in
the non-SLOB case is due to the fact PageSlab() takes a different path
out.

The page->index bits look like they are being used for determining
compound order, which is _completely_ bogus, and only happens to "work"
in a few cases. Christoph and I have repeatedly asked for someone to
explain what the hell those tests are there for, as right now they not
only look completely bogus, but they also stop us from booting on SLOB.
So far no one has provided any input on why those page->index BUG_ON()'s
have any right to exist.

So while having 2 out of 3 SLAB allocators in a bootable state might seem
like progress, I'd rather see kobjsize() fixed correctly. Even my initial
patches worked for all 3.

If no one can speak up to defend those bits, they should be killed off
before 2.6.26. Whether this is done in combination with your patch or
Christoph's patch or whatever else doesn't matter.
--
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/