On Mon, 17 Nov 2008 09:15:26 +0100 Ingo Molnar <mingo@xxxxxxx> wrote: > > * FUJITA Tomonori <fujita.tomonori@xxxxxxxxxxxxx> wrote: > > > This patch fixes swiotlb to use dev->coherent_dma_mask in > > alloc_coherent. Currently, swiotlb uses dev->dma_mask in > > alloc_coherent but alloc_coherent is supposed to use > > coherent_dma_mask. It could break drivers that uses smaller > > coherent_dma_mask than dma_mask (though the current code works for > > the majority that use the same mask for coherent_dma_mask and > > dma_mask). > > > > Signed-off-by: FUJITA Tomonori <fujita.tomonori@xxxxxxxxxxxxx> > > --- > > lib/swiotlb.c | 10 +++++++--- > > 1 files changed, 7 insertions(+), 3 deletions(-) > > Applied it with the changelog below to tip/core/urgent, thanks! > > I also flagged it for v2.6.28 inclusion. This bug was caused by the > removal of the GFP_DMA hack in swiotlb_alloc_coherent() in this cycle. > I havent seen it actually reported anywhere - have you perhaps?Or have > you found this via code review? This wasn't introduced by the removal of the GFP_DMA hack. It has been for ages, I think. I knew this issue but I thought that it's harmless and let it alone. But Grant Grundler said that there are some devices are troubled by this: http://marc.info/?l=linux-kernel&m=122379585203173&w=2 I fixed VT-d about this (bb9e6d65078da2f38cfe1067cfd31a896ca867c0) but somehow I forgot about swiotlb. I think that it would be fine to push this to 2.6.29 since seems that nobody hits this. But it's also fine to push it for 2.6.28 since it's theoretically a bug fix and pretty trivial. > Do we know roughly the range of devices/systems where there's a real > address range that cannot be DMA-ed to coherently, and an estimation > about how frequently they would be affected by this bug? I think that if a driver hits this bug, it's likely that an user sees kinda data corruption right after loading the driver. -- To unsubscribe from this list: send the line "unsubscribe linux-ia64" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
|