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: <Pine.LNX.4.64.0803281133190.17805@schroedinger.engr.sgi.com>
Date:	Fri, 28 Mar 2008 11:37:48 -0700 (PDT)
From:	Christoph Lameter <clameter@....com>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
cc:	Pekka Enberg <penberg@...helsinki.fi>,
	"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, Linus Torvalds wrote:

> 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).

That commit cleared a flag that was cleared later anyways....

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

Do we have confirmation that the revert actually does something? It 
certainly does not address the issues with inline page forwarding. And why 
are we forbidding page allocator allocs with __GFP_ZERO in interrupt 
context? Only __GFP_HIGHMEM needs kmap and only __GFP_HIGHMEM can cause 
trouble.

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

You may want to check SLAB recent bug list. There is still crap over there 
as well and AFAICT this is more severe than SLUB and its inherent in the 
complex scheme that we had to put in ther.
 
> 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!

__GFP_ZERO is cleared in one place when new_slab() calls allocate_slab(). 
The fallback code in 2.6.25 will go away in 2.6.26.


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