[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Pine.LNX.4.64.0706220628420.6142@blonde.wat.veritas.com>
Date: Fri, 22 Jun 2007 06:37:03 +0100 (BST)
From: Hugh Dickins <hugh@...itas.com>
To: Christoph Lameter <clameter@....com>
cc: 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>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Russell King <rmk@....linux.org.uk>
Subject: Re: Oops in a driver while using SLUB as a SLAB allocator
On Thu, 21 Jun 2007, Christoph Lameter wrote:
> On Fri, 22 Jun 2007, Hugh Dickins wrote:
>
> > However... what gives you confidence that flush_dcache_page is
> > never applied to other slab pages?
>
> Flush dcache page is supposed to run on pages not objects of varying
> length. It is suprising that this has not lead to earlier problems.
> Objects allocated this way may straddle a page boundary under some
> conditions and in that case virt_to_page may not lead to a page that
> covers the complete object that is supposed to be flushed. Hopefully the
> "size" of the allocated object were whole pages.
No, that's the wrong way round. Neither ARM nor PA-RISC expects
flush_dcache_page to flush any dcache when given a slab allocation:
they just expect it to pass through, not to oops.
Hugh
-
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