USB mass storage and ARM cache coherency
in [Kernel]
|
Prev: [PATCH 0/3] HID: make raw output callback more flexible
Next: kprobes: Disable booster when CONFIG_PREEMPT=y
From: Benjamin Herrenschmidt on 17 Feb 2010 05:10 On Wed, 2010-02-17 at 09:55 +0000, Russell King - ARM Linux wrote: > Nope. It's to do with mapping a buffer for DMA, and then doing PIO > reads/writes to it. > > With speculative prefetches, you have to deal with cache coherency with > hardware DMA on DMA unmap. If you've written to the buffer in violation > of the DMA API buffer ownership rules, then your writes get thrown away > resulting in immediate data corruption. Right, and this exact same problem will bite some embedded powerpc too I suppose :-) Hrm... actually not :-) We don't do the invalidate at unmap time today because we know 44x have such a broken prefetcher that we disable it ... interesting considering that there are machines around that do non-coherent DMA with 750's style chips who -do- have a prefetcher... damn, we have a bug :-) In any case, same problem here. See my reply to Oliver. Basically, the problem boils down to the dma_map/unmap being done at the wrong layer. The driver should simply not do these if it's going to do PIO over that range. Cheers, Ben. -- 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: Oliver Neukum on 17 Feb 2010 05:30 Am Mittwoch, 17. Februar 2010 11:18:01 schrieb Benjamin Herrenschmidt: > > No problem here. USB core does the mapping only if the low-level driver > > so requests. The only exception is in usb_buffer_alloc(), but that boils > > down to dma_alloc_coherent() > > Allright, so why do we need to "fix" anything ? Or is the whole thread > moot ? :-) The request a low-level driver does is all or nothing. Either DMA issues have to be handled by that driver alone, or a finer-grained description of the DMA requirements is needed. A fix using the latter approach is being worked on. Regards Oliver -- 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: Benjamin Herrenschmidt on 17 Feb 2010 05:30 On Wed, 2010-02-17 at 11:09 +0100, Oliver Neukum wrote: > > No problem here. USB core does the mapping only if the low-level driver > so requests. The only exception is in usb_buffer_alloc(), but that boils > down to dma_alloc_coherent() Allright, so why do we need to "fix" anything ? Or is the whole thread moot ? :-) It's pretty clear that between dma_map* and subsequent unmap, the memory is owned by the device and must not be touched by the CPU. If that is violated, then we have a driver bug. Cheers, Ben. -- 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: Benjamin Herrenschmidt on 17 Feb 2010 07:20 On Wed, 2010-02-17 at 11:23 +0100, Oliver Neukum wrote: > > The request a low-level driver does is all or nothing. Either DMA > issues have to be handled by that driver alone, or a finer-grained > description of the DMA requirements is needed. A fix using the latter > approach is being worked on. Well, that's what I'm trying to understand. IE. It's a pretty strong rule ... don't do CPU accesses between dma_map and unmap. So it's all in driver land at that stage. I'm not sure how the DMA requirements get into the picture here. IE. That rule is globally true. It's not going to hurt just non-coherent archs, it's going to hurt anybody using swiotlb too... So I don't see you need more info about the DMA requirements, but maybe I did miss something :-) Cheers, Ben. -- 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: Jamie Lokier on 17 Feb 2010 07:40
Russell King - ARM Linux wrote: > On Tue, Feb 16, 2010 at 10:07:20AM +0100, Oliver Neukum wrote: > > Am Dienstag, 16. Februar 2010 09:55:55 schrieb Shilimkar, Santosh: > > > > Would you care to elaborate on the exact nature of the bug you are fixing? > > > On the OMAP4 (ARM cortex-a9) platform, the enumeration fails because control > > > transfer buffers are corrupted. On our platform, we use PIO mode for control > > > transfers and DMA for bulk transfers. > > > > > > The current stack performs dma cache maintenance even for the PIO transfers > > > which leads to the corruption issue. The control buffers are handled by CPU > > > and they already coherent from CPU point of view. > > > > How does the mapping corrupt buffers? It might impact performance, but why > > do you see corruption? > > On map, buffers are cleaned if they're being used for DMA_TO_DEVICE and > DMA_BIDIRECTIONAL, or invalidated in the case of DMA_FROM_DEVICE. > > However, because ARM CPUs can now speculatively prefetch, just leaving it > at that results in corruption of buffers used for DMA. So we have to > invalidate DMA_FROM_DEVICE and DMA_BIDIRECTIONAL buffers on unmap to > ensure coherency with DMA operations. > > If the CPU writes to a DMA_FROM_DEVICE buffer between map and unmap, the > writes can sit in the cache, and on unmap, they will be discarded. > > Cleaning the cache on unmap is not an option; that too can lead to DMA > buffer corruption in the DMA case. Provided the buffers are cleaned on map for DMA_TO_DEVICE/DMA_BIDIRECTIONAL, I don't see how cleaning on unmap for DMA_FROM_DEVICE/DMA_BIDIRECTIONAL can cause corruption. The only way to get dirty cache lines while mapped is if the CPU did PIO to them. If it was real DMA, the second clean should be a no-op. (Assume it's all one or the other). Can you explain why cleanining the cache on unmap (as well as map, in DMA_BIDIRECTIONAL case) is not an option? Just curious, because I don't see what would go wrong. > USB and associated host driver must abide by the DMA API buffer > ownership rules otherwise the result will be data corruption; either > that or USB/host driver people need to have a discussion with the > DMA API authors to remove this sensible "restriction". Just in case my question gives the wrong impression, I agree that the DMA API must be followed. Additional flushes/cleans are not good for performance either. -- Jamie -- 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/ |