linux-kernel - Re: 2.6.25-rc7-git2: Reported regressions from 2.6.24

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: <alpine.LFD.1.00.0803281017500.14670@woody.linux-foundation.org>
Date:	Fri, 28 Mar 2008 10:27:44 -0700 (PDT)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Pekka Enberg <penberg@...helsinki.fi>
cc:	Christoph Lameter <clameter@....com>,
	"Rafael J. Wysocki" <rjw@...k.pl>,
	Pawel Staszewski <pstaszewski@...com.pl>,
	LKML <linux-kernel@...r.kernel.org>,
	Adrian Bunk <bunk@...nel.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Natalie Protasevich <protasnb@...il.com>
Subject: Re: 2.6.25-rc7-git2: Reported regressions from 2.6.24

On Fri, 28 Mar 2008, Pekka Enberg wrote:
> 
> On Fri, Mar 28, 2008 at 6:00 AM, Linus Torvalds
> <torvalds@...ux-foundation.org> wrote:
> >  And the fact is, passing in GFP_ZERO from the SLUB code is a bug
> >  regardless, because it unnecessarily does the dual memset().
> 
> We clear GFP_ZERO in new_slab() so the normal kmalloc()/kzalloc() path
> should be fine but don't do it for kmalloc_large() nor
> kmalloc_large_node(). Is that the bug here?

Dammit, NO.

The bug was that the commit I made (which was correct and robust) was then 
partially reverted by Christoph for no good reason. At that point, 
kmalloc_large() didn't even exist, so at that point the change was 
"technically correct" (since the only user of gfpflags really did end up 
clearing it somewhere deep in its callchain).

So when that original 3811dbf67162bd08412f1b0e02e554f353e93bdb happened, 
it wasn't an outright bug - but that doesn't make it right. That commit 
was always just a bug waiting to happen, because it just set things up for 
later problems by retaining that bit when it really shouldn't have been 
retained, and forcing all future callers to be careful. Which they 
obviously were not!

Yes, you can clear GFP_ZERO in multiple illogical places, and it will fix 
the bug. Or you can clear it in *one* place, that is in on the direct 
callchain from the person who actually does the memset(0), and even add a 
comment that says exactly what is going on.

So the fact is, commit 3811dbf67162bd08412f1b0e02e554f353e93bdb is and was 
total and utter crap. I've reverted it in my tree. It's crap not because 
it was buggy when it was put in, but because it was *fragile* when it was 
put in. And that fragility ended up causing a bug later.

I'm getting really tired of slub. It was supposed to be simpler code than 
slab, and yes, it's simpler, but it has been buggy as hell, and part of it 
has been that people just haven't been careful enough, and haven't written 
code to be defensive and easy-to-follow.

So the *last* thing we want to do is to clear GFP_ZERO in multiple subtle 
places based on new random code being added. We want to clear it at the 
top level, so that no other code never ever even has to _think_ about it!

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