Re: [RFT][PATCH] generic device DMA implementation

From: Manfred Spraul (manfred@colorfullife.com)
Date: Sat Dec 28 2002 - 15:05:38 EST


James Bottomley wrote:

>manfred@colorfullife.com said:
>
>
>>If multiple kmalloc buffers fit into one cacheline, then it can happen
>> all the time. But the smallest kmalloc buffer is 64 bytes [assuming
>>page size > 4096].
>>
>>
>
>Actually, I did forget to mention that on parisc non-coherent, the minimum
>kmalloc allocation is the cache line width, so that problem cannot occur.
>
>Hmm, perhaps that is an easier (and faster) approach to fixing the problems on
>non-coherent platforms?
>
>
How do you want to fix sendfile()?
Note that I'm thinking along the same line as reading an unaligned
integer: the arch must provide a trap handler that emulates misaligned
reads, but it should never happen, except if someone manually creates an
IP packet with odd options to perform an DoS attack. Restricting kmalloc
is obviously faster, but I'm not convinced that this really catches all
corner cases.

A memcpy() based dma_map implementation would have another advantage:
enable it on i386, and you'll catch everyone that violates the dma spec
immediately.

The only problem is that the API is bad - networking buffers are usually
2 kB allocations, 2 kB aligned.
The actual data area that is passed to pci_map_single starts at offset 2
and has an odd length. It's not possible to pass the information to
dma_map_single() that the rest of the cacheline is unused and that
double buffering is not required, despite the misaligned case.
Except for sendfile(), then double buffering is necessary.

--
    Manfred

- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/



This archive was generated by hypermail 2b29 : Tue Dec 31 2002 - 22:00:12 EST