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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
