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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ