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]

Date:	Sat, 29 Mar 2008 14:29:27 -0700 (PDT)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Christoph Lameter <clameter@....com>
cc:	"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 Sat, 29 Mar 2008, Christoph Lameter wrote:
>
> > If SLUB *ever* calls the page allocator with __GFP_ZERO set, it's a 
> > bug, and that has nothing to do with GFP_ATOMIC or anything else. Because 
> > SLUB uses its own logic for clearing the result.
> 
> Yes it uses its own logic if the object is managed by SLUB but not if the 
> object is too big and/or the allocation forwarded to the page allocator 
> or for other internal allocations of buffers etc.

Wrong.

It uses it's own logic for __GFP_ZERO *regardless* of size.

> > Why cannot you just admit it?
> 
> Admitting something that is not true is rather difficult.

You don't have a f*cking clue about this cocde that you're supposed to be 
maintaining, do you?

See "slab_alloc()". See the code:

	if (unlikely((gfpflags & __GFP_ZERO) && object))
		memset(object, 0, c->objsize);

and see how it does it regardless of anything else.

In short, if *any* code-path calls down to any allocator from that routine 
with GFP_ZERO set, it's a bug. No ifs, buts or maybes about it. It 
shouldn't do that, because the actual memset() is done by slab_alloc(), 
and should not be done ANYWHERE ELSE.

It has *nothing* to do with "object is too big" or anything else.

> So what you want is to forbid any use of
> 
> 	alloc_pages(__GFP_ZERO|...)

No. I want you to admit the bugs in code you maintain. I want you to admit 
that slab_alloc() does the memset(), and should NEVER EVER use __GFP_ZERO
for the page allocations.

I have told you about a million times now that THIS HAS NOTHING TO DO WITH 
interrupts or HIGHMEM or *anything* else. This is purely a SLUB issue.

But don't worry. I already fixed it by reverting your broken commit. I 
just wish you could follow code that you are supposed to be maintaining.

			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/