From nobody Thu Apr 2 15:39:00 2026 Received: from mail-lf1-f48.google.com (mail-lf1-f48.google.com [209.85.167.48]) (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 D000E199920 for ; Fri, 27 Mar 2026 12:42:07 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.167.48 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774615329; cv=none; b=Dzrx2cTT3L92y8lvtUiT2+RbEE/5CoswrxNojoqKZzwYvYq+IwbDNz9Kw1kpVdYzFoy1bGNEcTKy804MpYD+gsI5ZWqB55cYITqRf8WyxRyEmidmpt6nwHKJEU+JlZ/Z+S8+oHi+8l+vq2LAeEospTTmIAbj4W4sFKOKRb4mwYY= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774615329; c=relaxed/simple; bh=B3tp398WNbwm1ae+gWHLUuGz3BxoORfZ1NVIHaytnAg=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=btxP/7SnxYW6Ap4ZrnmVRxguvBjavz1uAvuDyzzppopcEdukKD/DTEGgLmPrWPvcRx2BhVPAbyXoVU0BjNXlvxaPP8IERmDekK4nvZX7A5+fweGjI9JqlfFfQSrQJzzUynKL0U8R/9AWSz2jID3MzI8ZR+X0ORA4BQ541QDKoi0= 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=C9vKBgE0; arc=none smtp.client-ip=209.85.167.48 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="C9vKBgE0" Received: by mail-lf1-f48.google.com with SMTP id 2adb3069b0e04-5a0ff30b240so2394988e87.0 for ; Fri, 27 Mar 2026 05:42:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1774615326; x=1775220126; 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=vnEhmrhTPA7Nd81/VP3XZfiniWMenGZwrrUyIBlvmYM=; b=C9vKBgE0xtvL8Jt4R7jq/jNUIy0sbgkauEQs/mBNZzAfUmhgyPSUM5Ow4bPERhwdaK ++ZA7ixGVWMJcW8PLQI4h0csbGtM3H5Ee9FlG6MzpX5+WLHy7zgCCKFJglqdPS0zg97o 85TNJHLNsc+0udA/iPRUcMP6jum219wgf6HQImW1f6Lgv1oIVDfjxUcbK6xcjeBYa4PI NauzZ+vyzdH2DhWqZAb/pQHqHZnNx2gwQtmzdJDax0IA3Q92OqCAUyzo5c04YmpO/KQ6 DkRLkBcft98X8VfxPN+DNfGGL+Q0S9Jg+p/5gv4vrKKlLxDxpoGtBYmBAosYaea9ywfA OBpw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1774615326; x=1775220126; 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=vnEhmrhTPA7Nd81/VP3XZfiniWMenGZwrrUyIBlvmYM=; b=jyU0UBFCigWjZAzqYForPEawh9XzkGZM0vlFAIb9s817i8KvYMg/uLOdY5S4KiLahM tw6itAECGnXnRKBHDoJoxfJzbsbsEDXJXHMCaYEnMYAOaDfXKnnuwqAdY0Ad9D4MaYud qh9u1up3uMeR65GZKJXiD3XTQbh3FbFHqdGwoINM9r0z/s2n6zxNh3rjwF8wyQFatkQM 50bIzTHjqLFdOT5nIsIL8tvz85qzn7wfg9HBqnqhxRxyXc26Nzgjod6l5RyMzBZJ6Ket 27ho87Ypum7/V18/quJFkds0cgJeXrOhURNOObFKJVboZWHavF3trZENqhjgS9D8+WuG JlTA== X-Forwarded-Encrypted: i=1; AJvYcCUmBT97ocwNjOwBcvIVW53utPeprhB6XPddfJ1PVWUxGSgh2Yd+WuHB/mQkqQU5fiK9l1+qqy7WF6A7+yM=@vger.kernel.org X-Gm-Message-State: AOJu0Yz47BMEbJ9xDY2pdv+sy/BU2JmvppOvgA3aLa5v7KUMtzciySI4 gn81NZxRTzrk0L6CTTAatkPJ6NTj7EgAMpJGDKHDzCFOwQHM8pLKvtFJ X-Gm-Gg: ATEYQzz+cP7GcoxKePGva3FL0dnreSSL+/axbjIJBl4vnIWUkMlH0yGYTML2Y1zAgbh 7ec9fLGYyn14c1cRaCvj93Tdr4EmiopXNnHdXXDZW4Am4CZBxXLKCnM/zMBn+m6RF2vY2LbRxaF Q4eR9Aa7Vatj+pSn9ZrXkjB8L+1UjFrZI3ADxjeFRn7z96rOQ6eCNTMreBSmvxNIR4MxONRPx/u xMPmJQiCqeFZ30vaCuzww1IiDBHxRkFBYlvJfX6bL6mqnVGHwAQgfHbr0btzDG6P99pDVmhith+ XgDwZl7VdCv0KOAaXOUmqqj8U9obJO1JkSPJvBz7KwzHnQfj/MwRJdW+Xj8PmcLI718dRrstKQC WDrue1P0VDaF7sJl66q2w/H3LVwt6UjPoCJY5xMSu2e7A44fC00pjbsUB5NsK4JVg7mpd5GVHGP HwiIiOFf4oYo70ZBlK4YZ+jTvANHNvDSKqtA== X-Received: by 2002:a05:6512:6c8:b0:5a2:5b88:a8a3 with SMTP id 2adb3069b0e04-5a2ab92854fmr1015552e87.31.1774615325628; Fri, 27 Mar 2026 05:42:05 -0700 (PDT) Received: from localhost ([188.234.148.119]) by smtp.gmail.com with ESMTPSA id 2adb3069b0e04-5a2a063efbasm1336127e87.14.2026.03.27.05.42.03 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 27 Mar 2026 05:42:04 -0700 (PDT) From: Mikhail Gavrilov To: m.szyprowski@samsung.com, robin.murphy@arm.com Cc: iommu@lists.linux.dev, linux-kernel@vger.kernel.org, linux-usb@vger.kernel.org, linux-mm@kvack.org, harry@kernel.org, vbabka@kernel.org, akpm@linux-foundation.org, stern@rowland.harvard.edu, linux@roeck-us.net, andy.shevchenko@gmail.com, hch@lst.de, Jeff.kirsher@gmail.com, catalin.marinas@arm.com, Mikhail Gavrilov Subject: [PATCH v2] dma-debug: suppress cacheline overlap warning when arch has no DMA alignment requirement Date: Fri, 27 Mar 2026 17:41:56 +0500 Message-ID: <20260327124156.24820-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. The cacheline overlap is only a real concern on architectures that require DMA buffer alignment to cacheline boundaries (i.e. where ARCH_DMA_MINALIGN >=3D L1_CACHE_BYTES). On architectures like x86_64 where dma_get_cache_alignment() returns 1, the hardware is cache-coherent and overlapping cacheline mappings are harmless. Suppress the EEXIST warning when dma_get_cache_alignment() is less than L1_CACHE_BYTES, indicating the architecture does not require cacheline-aligned DMA buffers. 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: same cacheline pair found, but no warning emitted Fixes: 2b4bbc6231d7 ("dma-debug: report -EEXIST errors in add_dma_entry") Link: https://bugzilla.kernel.org/show_bug.cgi?id=3D215740 Suggested-by: Harry Yoo Tested-by: Mikhail Gavrilov Signed-off-by: Mikhail Gavrilov --- v1 -> v2: - Moved fix from include/linux/slab.h (ARCH_KMALLOC_MINALIGN) to kernel/dma/debug.c per Harry Yoo's suggestion. - Instead of forcing cacheline-aligned allocations, suppress the warning when the architecture has no DMA alignment requirement (dma_get_cache_alignment() < L1_CACHE_BYTES). v1: https://lore.kernel.org/all/20260327055846.248829-1-mikhail.v.gavrilov@= gmail.com/ Reproducer module that triggers the bug reliably: https://bugzilla.kernel.org/attachment.cgi?id=3D309769 kernel/dma/debug.c | 1 + 1 file changed, 1 insertion(+) diff --git a/kernel/dma/debug.c b/kernel/dma/debug.c index 0677918f06a8..1a725edbbbf6 100644 --- a/kernel/dma/debug.c +++ b/kernel/dma/debug.c @@ -615,6 +615,7 @@ static void add_dma_entry(struct dma_debug_entry *entry= , unsigned long attrs) } else if (rc =3D=3D -EEXIST && !(attrs & DMA_ATTR_SKIP_CPU_SYNC) && !(entry->is_cache_clean && overlap_cache_clean) && + dma_get_cache_alignment() >=3D L1_CACHE_BYTES && !(IS_ENABLED(CONFIG_DMA_BOUNCE_UNALIGNED_KMALLOC) && is_swiotlb_active(entry->dev))) { err_printk(entry->dev, entry, --=20 2.53.0