Prev: s3c-fb: added patch series for s5pv210 and some features.
Next: linux-next: manual merge of the usb tree with the v4l-dvb tree
From: Mike Frysinger on 12 May 2010 00:40 On Tue, May 11, 2010 at 23:23, FUJITA Tomonori wrote: > Seems that kmalloc is not cacheline aligned on some architectures but > they works. Probably, we might be just lucky because in general they > allocate larger buffers than 64 for DMA via kmalloc and the buffers > are aligned on the size? i think the magic combo is: - DMA buffer is written to (receive) - some driver state is in the same cacheline as the DMA buffer - that driver state is used after the flush but before the DMA finishes - only on arches that need software cache coherency so i could see this not being an obvious issue for many people -mike -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: FUJITA Tomonori on 12 May 2010 01:40 On Wed, 12 May 2010 00:35:45 -0400 Mike Frysinger <vapier.adi(a)gmail.com> wrote: > On Tue, May 11, 2010 at 23:23, FUJITA Tomonori wrote: > > Seems that kmalloc is not cacheline aligned on some architectures but > > they works. Probably, we might be just lucky because in general they > > allocate larger buffers than 64 for DMA via kmalloc and the buffers > > are aligned on the size? > > i think the magic combo is: > - DMA buffer is written to (receive) > - some driver state is in the same cacheline as the DMA buffer > - that driver state is used after the flush but before the DMA finishes > - only on arches that need software cache coherency > > so i could see this not being an obvious issue for many people Yeah, we don't hit such condition everyday. And as I said, SCSI usually uses kmalloc'ed buffers rather than the cache size (buffers are aligned on roundup_pow_of_two(the allocated size)). But I think that we want to fix this issue explicitly. I guess that it would be better to start a new thread about this issue. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Marc Gauthier on 12 May 2010 08:40 Mike Frysinger wrote: > On Tue, May 11, 2010 at 23:23, FUJITA Tomonori wrote: >> Seems that kmalloc is not cacheline aligned on some architectures but >> they works. Probably, we might be just lucky because in general they >> allocate larger buffers than 64 for DMA via kmalloc and the buffers >> are aligned on the size? > > i think the magic combo is: > - DMA buffer is written to (receive) [...] > - only on arches that need software cache coherency In particular, when the architecture port uses cache invalidates that throw away dirty lines. They're equivalent to writing old data to a cache line, so an unrelated kmalloc allocation in the same cache line gets corrupted. So true, not all architectures need the extra alignment. (And maybe some get lucky too, don't know.) -Marc PS. Sorry about the gratuitous [LKML] in the subject line, mea culpa. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Mike Frysinger on 12 May 2010 10:40 On Wed, May 12, 2010 at 01:28, FUJITA Tomonori wrote: > I guess that it would be better to start a new thread about this issue. will do -mike -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Mike Frysinger on 12 May 2010 10:40
On Wed, May 12, 2010 at 08:35, Marc Gauthier wrote: > Mike Frysinger wrote: >> On Tue, May 11, 2010 at 23:23, FUJITA Tomonori wrote: >>> Seems that kmalloc is not cacheline aligned on some architectures but >>> they works. Probably, we might be just lucky because in general they >>> allocate larger buffers than 64 for DMA via kmalloc and the buffers >>> are aligned on the size? >> >> i think the magic combo is: >> - DMA buffer is written to (receive) > [...] >> - only on arches that need software cache coherency > > In particular, when the architecture port uses cache invalidates that > throw away dirty lines. They're equivalent to writing old data to a > cache line, so an unrelated kmalloc allocation in the same cache line > gets corrupted. true; i was thinking of the Blackfin implementation that only has a FLUSH+INV insn (i complain about the lack of a pure INV insn every now and again) -mike -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |