linux-kernel - Re: Oops in a driver while using SLUB as a SLAB allocator

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.0.98.0706220937271.3593@woody.linux-foundation.org>
Date:	Fri, 22 Jun 2007 09:40:45 -0700 (PDT)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Hugh Dickins <hugh@...itas.com>
cc:	Christoph Lameter <clameter@....com>,
	Nicolas Ferre <nicolas.ferre@....atmel.com>,
	ARM Linux Mailing List 
	<linux-arm-kernel@...ts.arm.linux.org.uk>,
	Linux Kernel list <linux-kernel@...r.kernel.org>,
	Marc Pignat <marc.pignat@...s.ch>,
	Andrew Victor <andrew@...people.com>,
	Pierre Ossman <drzeus@...eus.cx>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Russell King <rmk@....linux.org.uk>
Subject: Re: Oops in a driver while using SLUB as a SLAB allocator

On Fri, 22 Jun 2007, Hugh Dickins wrote:
>
> On Thu, 21 Jun 2007, Christoph Lameter wrote:
> 
> > Maybe this will address the issue on ARM?
> 
> Looks like it would indeed address the immediate issue on ARM -
> IF they've no particular reason to be using kmalloc there.

I think the right thing to do is do both of these things. I already 
applied Hugh's patch - it seemed like a total nobrainer to do at this 
stage in the 2.6.22 -rc series. But that doesn't mean that we should not 
_also_ look at "flush_dcache_page()" users.

I do think that even just the name (the ".._page()" part) makes it obvious 
that it was designed for page-level allocations, not kmalloc(). So I think 
Christoph's patch makes sense in that context.

At the same time, I do think that the whole notion of flushing the D$ is 
certainly something that makes sense for kmalloc() allocations also, and 
maybe people do actually do small DMA allocations and Christophs patch 
would break that.

End result: for 2.6.22, I think the patch from Hugh that I already applied 
is the right thing. 

But as to 2.6.23 and onward.. I dunno.

		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/