James Bottomley wrote:
>The problem really only occurs if the CPU can modify part of a cache line
>while a device has modified memory belonging to another part. Now a flush
>from the CPU will destroy the device data (or an invalidate from the driver
>destroy the CPU's data). The problem is effectively rendered harmless if only
>data going in the same direction shares a cache line (even if it is for
>different devices). It strikes me that this is probably true for network data
>and would explain the fact that I haven't seen any obvious network related
>corruption.
>
>
Yes. Networking usually generates exclusive cachelines.
I'm aware of two special cases:
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].
Is your cache line >= 128 bytes?
Or sendfile() of a mmap'ed file that is modified by userspace. That is
the recommended approach for zerocopy tx, but I'm not sure which apps
actually use that. IIRC DaveM mentioned the approach.
Additionally, the TCP checksum could catch the corruption and resent the
packet - you wouldn't notice the corruptions, unless you use hw checksums.
--
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