From: Mikhail Gavrilov <mikhail.v.gavrilov@gmail.com>
To: vbabka@kernel.org, harry.yoo@oracle.com, akpm@linux-foundation.org
Cc: hao.li@linux.dev, cl@gentwo.org, rientjes@google.com,
roman.gushchin@linux.dev, linux-mm@kvack.org,
linux-kernel@vger.kernel.org, linux-usb@vger.kernel.org,
stern@rowland.harvard.edu, linux@roeck-us.net,
andy.shevchenko@gmail.com, hch@lst.de, Jeff.kirsher@gmail.com,
Mikhail Gavrilov <mikhail.v.gavrilov@gmail.com>
Subject: [PATCH] mm/slab: align kmalloc to cacheline when DMA API debugging is active
Date: Fri, 27 Mar 2026 10:58:46 +0500 [thread overview]
Message-ID: <20260327055846.248829-1-mikhail.v.gavrilov@gmail.com> (raw)
When CONFIG_DMA_API_DEBUG is enabled, the DMA debug infrastructure
tracks active mappings per cacheline and warns if two different DMA
mappings share the same cacheline ("cacheline tracking EEXIST,
overlapping mappings aren't supported").
On x86_64, ARCH_KMALLOC_MINALIGN defaults to 8, so small kmalloc
allocations (e.g. the 8-byte hub->buffer and hub->status in the USB
hub driver) frequently land in the same 64-byte cacheline. When both
are DMA-mapped, this triggers a false positive warning.
This has been reported repeatedly since v5.14 (when the EEXIST check
was added) across various USB host controllers and devices including
xhci_hcd with USB hubs, USB audio devices, and USB ethernet adapters.
Raise ARCH_KMALLOC_MINALIGN to L1_CACHE_BYTES when CONFIG_DMA_API_DEBUG
is enabled, ensuring each kmalloc allocation occupies its own cacheline
and eliminating the false positive.
Verified with a kernel module reproducer that performs two kmalloc(8)
allocations back-to-back and DMA-maps both:
Before: allocations share a cacheline, EEXIST fires within ~50 pairs
After: 64 pairs allocated, all in separate cachelines, no warning
Fixes: 2b4bbc6231d7 ("dma-debug: report -EEXIST errors in add_dma_entry")
Link: https://bugzilla.kernel.org/show_bug.cgi?id=215740
Suggested-by: Alan Stern <stern@rowland.harvard.edu>
Suggested-by: Guenter Roeck <linux@roeck-us.net>
Tested-by: Jeff Kirsher <Jeff.kirsher@gmail.com>
Tested-by: Mikhail Gavrilov <mikhail.v.gavrilov@gmail.com>
Signed-off-by: Mikhail Gavrilov <mikhail.v.gavrilov@gmail.com>
---
Reproducer module that triggers the bug reliably:
https://bugzilla.kernel.org/attachment.cgi?id=309769
include/linux/slab.h | 13 +++++++++++++
1 file changed, 13 insertions(+)
diff --git a/include/linux/slab.h b/include/linux/slab.h
index 15a60b501b95..f044956e17c1 100644
--- a/include/linux/slab.h
+++ b/include/linux/slab.h
@@ -536,6 +536,19 @@ static inline bool kmem_dump_obj(void *object) { return false; }
#endif
#endif
+/*
+ * Align memory allocations to cache lines if DMA API debugging is active
+ * to avoid false positive DMA overlapping error messages.
+ */
+#ifdef CONFIG_DMA_API_DEBUG
+#ifndef ARCH_KMALLOC_MINALIGN
+#define ARCH_KMALLOC_MINALIGN L1_CACHE_BYTES
+#elif ARCH_KMALLOC_MINALIGN < L1_CACHE_BYTES
+#undef ARCH_KMALLOC_MINALIGN
+#define ARCH_KMALLOC_MINALIGN L1_CACHE_BYTES
+#endif
+#endif
+
#ifndef ARCH_KMALLOC_MINALIGN
#define ARCH_KMALLOC_MINALIGN __alignof__(unsigned long long)
#elif ARCH_KMALLOC_MINALIGN > 8
--
2.53.0
next reply other threads:[~2026-03-27 5:58 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-27 5:58 Mikhail Gavrilov [this message]
2026-03-27 6:37 ` Harry Yoo (Oracle)
2026-03-27 6:50 ` Mikhail Gavrilov
2026-03-27 8:00 ` Harry Yoo (Oracle)
2026-03-27 8:07 ` Mikhail Gavrilov
2026-03-27 8:43 ` Harry Yoo (Oracle)
2026-03-27 10:25 ` Mikhail Gavrilov
2026-03-27 10:39 ` Harry Yoo (Oracle)
2026-03-27 6:41 ` Guenter Roeck
2026-03-27 12:26 ` Catalin Marinas
2026-03-27 12:34 ` Andy Shevchenko
2026-03-27 14:09 ` Marek Szyprowski
2026-03-27 14:30 ` Vlastimil Babka (SUSE)
2026-03-27 14:37 ` Mikhail Gavrilov
2026-03-27 14:41 ` Marek Szyprowski
2026-03-27 14:55 ` Marek Szyprowski
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260327055846.248829-1-mikhail.v.gavrilov@gmail.com \
--to=mikhail.v.gavrilov@gmail.com \
--cc=Jeff.kirsher@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=andy.shevchenko@gmail.com \
--cc=cl@gentwo.org \
--cc=hao.li@linux.dev \
--cc=harry.yoo@oracle.com \
--cc=hch@lst.de \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-usb@vger.kernel.org \
--cc=linux@roeck-us.net \
--cc=rientjes@google.com \
--cc=roman.gushchin@linux.dev \
--cc=stern@rowland.harvard.edu \
--cc=vbabka@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox