From nobody Thu Apr 2 17:23:44 2026 Received: from mail-ej1-f46.google.com (mail-ej1-f46.google.com [209.85.218.46]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 711202D7DC4 for ; Fri, 27 Mar 2026 05:58:56 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.218.46 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774591137; cv=none; b=dLH3plk5b2Oq5z1o9RKuoEyLM4npqvvWurxg1qeaWrz04w57lj2H3sZk/aPKWeF1fqenSznV5f3dvVXisqTzsuKvyvXxeF1i1fbKuDTmR5W8qA1bPkrkacbKhRe+Bv5MwrnYPd/erJV5QdcwkXGEBQA1vUvnIcqzNkVqNRUUgjs= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774591137; c=relaxed/simple; bh=bO8hvN+mMZp+ue+7KHvHFBCUiRV75jZw5gll4WkqLVE=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=nfEpD5Yw7k9MM1g2dvGlL6C+DHJAWibJ3GU2Fd0hR00MpOq4kvVnI4+b+Pubekr9w3MBa6yB84qT+6bloFk4TmHWmJPsKb/LjRHEozuH/1/ib23WpdihSOBVgRxejnBCj++29s+JaBtlSub4vr9+ovrUqNad3M0i11QHajV6dTA= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=rN056wDE; arc=none smtp.client-ip=209.85.218.46 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="rN056wDE" Received: by mail-ej1-f46.google.com with SMTP id a640c23a62f3a-b97ba4c2be2so233683466b.1 for ; Thu, 26 Mar 2026 22:58:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1774591135; x=1775195935; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=kPvwNT2+pm09/nglousARL1BK0XMbSM7sYGP9rdShSQ=; b=rN056wDErR3tVmdzmaKKB0RJypDDBroAeg++C8SJSmWvDAGcHfGuufXeteQmnuAK4E cqwyUXVLetPAALu/UN7y7pwq4k5gXAmJ9rWhQtv4uZ8vcN+a//LHXSeTJwf0zoz1zCNb v+SBh59CVKPLWsQw6Eo5sIDF89gLSvpYAvijSSoCf46FgaICDFNu/YUcps6S4rNVdbds uP9Qpn1IhTQfCLHO4QmU5jOqU/oxDOKAhnO/vRCxQHDdEEnE8R0dmcRQ2dCv+/L7QCpF IeJf7MLXU3rHusVSSEJdUaObDSTGkq/Mym3jBRzRwItsbVVIoudg54HUjVZ6BXeMzYOZ v65w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1774591135; x=1775195935; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=kPvwNT2+pm09/nglousARL1BK0XMbSM7sYGP9rdShSQ=; b=OHEE5cMImig/PvSbDK1Qat4KlMM+I3GaK29S2LeQd8QyzAkeRgNymJg0Geh2vubClN Jzbk9QrS+sLPpb4KXmWJwDmOlpFYYqnwDzO5cyOAQ0/z6vFCE/ARTZcteaELpWmrWEXu e7BmL/t7WS4Ko5Pfv+H6rpKddJzheN0IiZFZUPbrDt8ao0aGDERs+irMM6gspHCdO65w qlY9pDT5sfnkiOPLJX79/V+e1hvV/PNDB1vx5wZgr1AGfhQouPizjmLDEMpzuyMhfGln ZrU9nFog/WzP7bN+sNaTSkiOChG4jQl21a1yfBXQ3iu+4ise2d5VPfAujUrOsZYHLmJD G5CQ== X-Forwarded-Encrypted: i=1; AJvYcCViGu2Olz0QvY7n64HEngFB7wiq0NH0iVWtpUNu/5Q2K/AKd06Bun06oYfUya8EuMVLtZSGBibUwavUBVY=@vger.kernel.org X-Gm-Message-State: AOJu0Yya9MRecSGQmSME9FCweJFvTVuIumwIb32zo+1rIMQsksHCw9fl Bkpw9TeCwxQJQe/wdW+wBdgCFymlfu7Vi4otKatdl96wkdwDqqFMIq0A X-Gm-Gg: ATEYQzxHWr+Lm6qeub3jNTeMx0qVwPg7gxQI1N1C7BA1YTHbHe3erMKsblXRC0YxKu4 8+5Fi6POZkN7x/o1cC7CEBM4MLtqE3iQv8FX5axZKn5t+1LJ4nWquzUpRBH5EQvfWHbQVSjcYdX YRcSyjFrkyPwRc4hjTnf2jddLxRRCEvN27Ar9EUXMMdYmK50XoCw/TgsSDg+XkZsbVI54U3OTfh uYsLk5ISPX6fASXol95hLqAk9gFbaPW4TqSiMz8KiZJTZ1Uga1t1vWyBI8Y13jaXofsXniGbk9c 6VBic4MvMkFtfxu5+LJPlj9Mm7yE74ef3F+jXslxxF42hrK2MVx6aSh2IWliCKpsIh3lw3k1YVp 5q4UypZ0jF2rgLQ600pwZ8a1A4XYg1CSsv9HHpYbu+NMYF113OSDwvgUfSGi/YT0oPWEnIuxO+h Xfspbir281LOHcHczBXzfPmm7zj0qijq2kzNx1onrJXig= X-Received: by 2002:a17:907:944b:b0:b9b:3a4f:ee86 with SMTP id a640c23a62f3a-b9b507a4c11mr61540566b.26.1774591134473; Thu, 26 Mar 2026 22:58:54 -0700 (PDT) Received: from localhost ([178.214.243.78]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-b9b20265cc0sm208461466b.15.2026.03.26.22.58.51 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 26 Mar 2026 22:58:53 -0700 (PDT) From: Mikhail Gavrilov 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 Subject: [PATCH] mm/slab: align kmalloc to cacheline when DMA API debugging is active Date: Fri, 27 Mar 2026 10:58:46 +0500 Message-ID: <20260327055846.248829-1-mikhail.v.gavrilov@gmail.com> X-Mailer: git-send-email 2.53.0 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" 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=3D215740 Suggested-by: Alan Stern Suggested-by: Guenter Roeck Tested-by: Jeff Kirsher Tested-by: Mikhail Gavrilov Signed-off-by: Mikhail Gavrilov Reviewed-by: Catalin Marinas Reviewed-by: Guenter Roeck --- Reproducer module that triggers the bug reliably: https://bugzilla.kernel.org/attachment.cgi?id=3D309769 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) { retur= n false; } #endif #endif =20 +/* + * 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 --=20 2.53.0