>> which causes stack corruption: on the PPC
>> 440GP, pci_map_single() with PCI_DMA_FROMDEVICE just invalidates the
>> cache for the region being mapped. However, if a buffer is smaller
>> than a cache line, then two bad things can happen.
> There is no allocation scheme legal for PCI DMA which gives you
> smaller than a cacheline of data, this includes SLAB. This is why
> stack buffers and the like are illegal for PCI DMA.
>> The solution to this was simply to use kmalloc() to allocate buffers
>> instead of using automatic variables.
>> However, this leads to my first question: is this safe on all
> It must be. If the architecture allows SLAB to give smaller than
> cacheline sized data, it must handle PCI DMA map/unmap flushing
> in an appropriate fashion (ie. handle sub-cacheline buffers).
>> DMA-mapping.txt says kmalloc()'ed memory is OK for DMAs and does not
>> mention cache alignment.
> It doesn't mention cache alignment because that is an implementation
> specific issue. The user of the interfaces need not be concerned
> about any of this.
> There need be no changes to the documentation. If you do as the
> documentation states (use kmalloc or get_free_page to get your
> buffers) then it will just work.
On a non-SMP system, would it be OK to map all the memory
without memory coherency enabled? You seem to be implying that
one only needs to implement some mechanism in pci_map_single()
to handle flushing cache lines (write back, then invalidate).
This would be useful for Macs.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to email@example.com
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/