[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <467FC939.3080603@rfo.atmel.com>
Date: Mon, 25 Jun 2007 15:55:05 +0200
From: Nicolas Ferre <nicolas.ferre@....atmel.com>
To: Russell King <rmk+lkml@....linux.org.uk>,
Hugh Dickins <hugh@...itas.com>,
Andrew Victor <andrew@...people.com>
CC: Christoph Lameter <clameter@....com>,
Linus Torvalds <torvalds@...ux-foundation.org>,
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>
Subject: Re: Oops in a driver while using SLUB as a SLAB allocator
Hugh Dickins :
> On Sun, 24 Jun 2007, Russell King wrote:
>> On Sun, Jun 24, 2007 at 11:24:16AM +0100, Hugh Dickins wrote:
>>> On Sun, 24 Jun 2007, Russell King wrote:
>>>> On Fri, Jun 22, 2007 at 07:39:33PM +0100, Hugh Dickins wrote:
>>>>
>>>> Please forward the original problem report.
>>> Done.
>> Okay, that seems to back up my suspicions - it's definitely AT91-based.
>> Since AT91-based machines do not have a DMA coherent cache,
>> arch_is_coherent() must be defined to '0'. The only way that kmalloc
>> could be reached is if that were defined to something other than '0',
>> and if that's done on a machine with DMA incoherent caches, that will
>> lead to data corruption.
>
> Yes, having looked through that now, I agree with you 100%.
AT91 _is_ defined with the arch_is_coherent() switch set to 0 (in
include/asm-arm/memory.h and not overloaded).
>> I think we need to wait for Nicolas to respond on this issue before
>> running headlong into applying a sticky plaster for something which is
>> actually a deeper issue.
>
> No need for Nicolas to respond, I think I've found what's "wrong":
> see below.
>
>> However, the arch_is_coherent() path _is_ buggy as it stands, but in
>> more than the way identified thus far. Eg, it doesn't set __GFP_DMA
>> appropriately for various DMA masks, so it might return DMA inaccessible
>> memory.
Ok it is bad but, in AT91, all memory is accessible with DMA.
[..]
> The slub allocation which gives rise to Nicolas' oops in not in
> ARM, but (I'm guessing) in drivers/mmc/core/sd.c: one of those
> status = kmalloc(64, GFP_KERNEL);
> where status is passed down for the response from mmc_sd_switch.
True, the oops appears after a mmc switch command (#6 command).
[..]
Not sure I can add much to what Hugh has said. If you need some more
precision anyway, I will try to answer.
Regards,
--
Nicolas Ferre
-
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