Replying to both here. On Fri, Dec 01, 2023 at 11:21:40AM -0500, Alan Stern wrote: > On Fri, Dec 01, 2023 at 01:17:43PM +0100, Ferry Toth wrote: > > > A non-cache coherent platform would either have the kmalloc() > > > allocations aligned or it would bounce those small, unaligned buffers. > > > > It would? Or it always has? It depends on the configuration. arm64 does the bounce as it opted in to CONFIG_DMA_BOUNCE_UNALIGNED_KMALLOC. > > > So it doesn't seem right to issue a warning on x86 where kmalloc() > > > minimum alignment is 8 and not getting the warning on a non-coherent > > > platform which forces the kmalloc() alignment. > > > > If *all*non-coherent platforms implement either correct alignment or bounce > > buffer, and on (coherent) x86 we get an WARN, then it is a false alarm > > right? > > > > That is exactly my question (because I have no idea which platforms have > > non-coherent caches). > > Don't forget, not all DMA buffers are allocated by kmalloc(). A buffer > allocated by some other means might not be aligned properly and might > share a cache line with another buffer. > > Or you might have a single data structure that was allocated by > kmalloc() and then create separate DMA mappings for two members of that > structure. If the two members are in the same cache line, that would be > an error. Indeed, so to be sure we don't trip over other false alarms, we'd also need to force ARCH_DMA_MINALIGN to be at least a cache-line size. That's used in some structures to force a static alignment of various members that take DMA transfers. After that, anything reported might actually be a potential issue, not a false alarm. However, I wonder whether we'd actually hide some genuine problems. Let's say x86 gets some DMA corruption when it tries to DMA 8 bytes into two adjacent buffers because of some DMA buffer overflow, nothing to do with cache lines. You enable the DMA API debugging to see if it reports anything and it suddenly starts working because of the forced minimum alignment. -- Catalin
