From nobody Mon May 25 05:13:50 2026 Received: from mail-lf1-f42.google.com (mail-lf1-f42.google.com [209.85.167.42]) (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 AC78D377ED7 for ; Mon, 18 May 2026 11:32:59 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.167.42 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779103983; cv=none; b=QSz70JlIOpfkWSJCPZKwMHxl8S91s/qM9rURWrlvo/WKG0VGdBhzHZ1C+q1MI8caqunEon1toY7iw41AMRHvw7A97UilqWPP9xE5+p+bt4h7yIpf29zYMRqMJWNUSOYT4ehwlj6PgpKIkKbVyCWjCZmv+8IpU5ufyD1pQllPXPc= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779103983; c=relaxed/simple; bh=RJWstnPwMeFt+IyKVb11wv2216Fz1HIRtY5LHVF/Ouc=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=LmPZH9xFxMmJI03xARTGrat8Mr/XxEmBeX5nEWfg9TVWUOjjaP5ioSWnQ0vPPRjT7g+H0DK8EiwyKfFTr7N9yL35CZdEgk5E3UmVGEJn3LR5ZUVnTyo//buWLVdaNkL6fK7Spskx/YZt8hGEE1Bl019u1kuXFCTPR0wRhk0vkLg= 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=U++qphck; arc=none smtp.client-ip=209.85.167.42 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="U++qphck" Received: by mail-lf1-f42.google.com with SMTP id 2adb3069b0e04-5a62f43b76aso2149998e87.3 for ; Mon, 18 May 2026 04:32:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1779103977; x=1779708777; 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=v5Hzt13YTTWOWMVMt3KTq767/BlWjWJAOzpQdOL+rYk=; b=U++qphckOCYepwdhDn3jM6juAmbAW04onxCYRwUAt/pyhNYVUUVIaWpifbDFgOv+Ax 8zUyg7+HsdEcYid57kyhtfTTTODeuC6ISQaKM2hs7bdUALBb4t8mnPe4RWur9mWuBug4 83/UZg7DcgU7e6KPG3cupXptx29vC4PO7hBWMjAoGJzOJViF7goE45PuHPY1EeFIO3lB B7MQhwTxRPXCa/FsgdHrSmPYkOiZLJ5YvKOXI53BGBBNdPVLX+1QPiLa6nqc83UAZnuT y0lOhmuPvQ9mQqitZ9MpZAITanouRg8P/9B7Gns0W1sf22k/k8noL8HXjTQ/Yx24MQfT HXVQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1779103977; x=1779708777; 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=v5Hzt13YTTWOWMVMt3KTq767/BlWjWJAOzpQdOL+rYk=; b=F8uI2IR6rUOK3RoRhZw/naHsvv0BBDzWExjvoLVk23DP17QJj7TmQY670b8UeWJTDZ jDCEnJeRyF6s3G/fhqgGHpmrnWaq8jaollYr9IGc42uPsWgZ1PMCyiy1DEUALAg1jiTJ V2RAliXVfA46TKaQ8Ahl5+gn33UbcwvhvZW6W/PJJ0rCRZ9Z5UTHg4XrLZoW6Xgu6YY1 rX0evrFDE2uka8RhNWDvY8hXshBdYS6wLLWQOQavvTk1IpjU8vOFqctnAa/c3gldBHKG tc7qBpdtrDlcDl89tWYQ/1GJOBYfwOTdxBfiKp+ReAuI/o6Gq91UOGisZgKsalyaxMwj rnLA== X-Forwarded-Encrypted: i=1; AFNElJ88J07p11nHGORJIPQ231oKheSA9zhMq43dTxfTehRLmIv/QGh0evXu/3ZMWDb4kf2MuvI2dSu592w82oU=@vger.kernel.org X-Gm-Message-State: AOJu0Yyfavv4F4Fk5iTCvblpJqEecR+vpMUbkO0YAfXhZ7lyM9y8TZDe zKxoI+Mt6WLtJ91wD3Ah0R7pHi89qsKExCJOoxAlqJeD/0ixaWFrWADS X-Gm-Gg: Acq92OFAQHy7bbetdGcG+63/YMfCjzoF3Y5WZZIj5Ud2fcsb2AmZDsqL6d1CDqCv13c Y9kV/tzmjA+Lh3mA1V6hX8hBHLGFvqKCe8gRWxZ6b+gHEYlhOcqB3zB4pOfsP6GeywuRJ8V7sNC qWjmQ4oVQ8Uue5WD5fdyq6hAK7mPbNzcovAddT0ENTBoTYMpqTdmyfOuSjUVnI+8rFVwtKceVL1 4SnEWDpIhVnGGgu7RsgZefEFVuF1No0ZVrha3dhLyeXfz2Z8Q+m8b+sdVygg8cRa9Xjdn5Jdx1x rTAo7/IU6MXBZQJqIe6cWkHc2eP7s2uZgOadZK7ecDO/xRCXNRfDSDfIcNIsb3sdOa5o4lysY76 m2QRQHGAGnzPj6cWDPypR0oh1HbZxv1zWTYZ+sZld39mO7SE74/glvUFj+NEGEDtm8jizYo6uRG QFGTR6f0HLO6ELg+i53qewrLSNc4GfRv0eYE43AxC5+G4= X-Received: by 2002:a05:6512:32c6:b0:5a8:8870:70fe with SMTP id 2adb3069b0e04-5aa0e60b31dmr4206317e87.8.1779103976737; Mon, 18 May 2026 04:32:56 -0700 (PDT) Received: from localhost ([188.234.148.119]) by smtp.gmail.com with ESMTPSA id 38308e7fff4ca-3958874ffbbsm11403481fa.27.2026.05.18.04.32.55 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 18 May 2026 04:32:56 -0700 (PDT) From: Mikhail Gavrilov To: m.szyprowski@samsung.com Cc: hch@lst.de, robin.murphy@arm.com, djbw@kernel.org, akpm@linux-foundation.org, catalin.marinas@arm.com, harry@kernel.org, ming.lei@redhat.com, leon@kernel.org, iommu@lists.linux.dev, linux-kernel@vger.kernel.org, Mikhail Gavrilov Subject: [PATCH] dma-debug: skip cacheline overlap tracking on cache-coherent architectures Date: Mon, 18 May 2026 16:32:51 +0500 Message-ID: <20260518113251.64844-1-mikhail.v.gavrilov@gmail.com> X-Mailer: git-send-email 2.54.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" The dma-debug cacheline overlap tracking emits two distinct warnings when multiple DMA mappings share a cacheline: 1. add_dma_entry() calls err_printk("cacheline tracking EEXIST, overlapping mappings aren't supported\n") on every -EEXIST from active_cacheline_insert(). 2. active_cacheline_inc_overlap() calls WARN_ONCE("exceeded %d overlapping mappings of cacheline %pa\n", ...) when the 3-bit per-cacheline overlap counter in the dma_active_cacheline radix tree would saturate past ACTIVE_CACHELINE_MAX_OVERLAP (=3D 7). Commit 3d48c9fd78dd ("dma-debug: suppress cacheline overlap warning when arch has no DMA alignment requirement") suppressed (1) on architectures where hardware bus snooping makes cacheline-overlapping DMA mappings safe. The same reasoning applies to (2): the tracking is pure overhead on those architectures, and (2) still fires under real workloads, e.g. heavy NVMe block I/O on x86_64: DMA-API: exceeded 7 overlapping mappings of cacheline 0x... WARNING: kernel/dma/debug.c:465 at add_dma_entry+0x394/0x410 Call Trace: add_dma_entry+... debug_dma_map_phys+... dma_map_phys+... blk_dma_map_iter_start+... nvme_map_data+... The block layer routinely produces nine or more concurrent in-flight mappings whose buffers share a single cacheline. On hardware-coherent systems this is harmless, but it saturates the tag-based overlap counter and produces a splat indistinguishable from a real driver bug. Extend the gate to skip the cacheline overlap tracking entirely on cache-coherent architectures, mirroring the DMA_TO_DEVICE early-return that already exists for the same "tracking is unnecessary" reason. The helper dma_debug_cacheline_tracking_needed() captures the condition and is symmetric to the existing add_dma_entry() check. The same DMA_BOUNCE_UNALIGNED_KMALLOC + SWIOTLB suppression that commit 03521c892bb8 ("dma-debug: don't report false positives with DMA_BOUNCE_UNALIGNED_KMALLOC") added to (1) applies here for the same reason: unaligned kmalloc buffers are bounced through aligned swiotlb buffers, so the original cacheline overlap never reaches DMA. The helper preserves both suppression conditions. Reproducer (out-of-tree module): map a single 8-byte buffer with dma_map_single(..., DMA_BIDIRECTIONAL) nine times in a row. The 9th call deterministically fires the WARN_ONCE on an unfixed kernel; with this patch applied no warning is emitted regardless of the number of overlapping mappings. Without this patch (n_maps=3D9): DMA-API: exceeded 7 overlapping mappings of cacheline 0x00000000071d7dbe WARNING: kernel/dma/debug.c:465 at add_dma_entry+0x39e/0x410 [...] With this patch (n_maps=3D1000): dma_debug_overlap_repro: 1000/1000 mappings active [no warning] Link: https://lore.kernel.org/all/ZwxzdWmYcBK27mUs@fedora/ Fixes: 3b7a6418c749 ("dma debug: account for cachelines and read-only mappi= ngs in overlap tracking") Tested-by: Mikhail Gavrilov Signed-off-by: Mikhail Gavrilov --- kernel/dma/debug.c | 35 +++++++++++++++++++++++++++++++++++ 1 file changed, 35 insertions(+) diff --git a/kernel/dma/debug.c b/kernel/dma/debug.c index 1a725edbbbf6..2d1609b9d362 100644 --- a/kernel/dma/debug.c +++ b/kernel/dma/debug.c @@ -474,6 +474,35 @@ static int active_cacheline_dec_overlap(phys_addr_t cl= n) return active_cacheline_set_overlap(cln, --overlap); } =20 +/* + * Whether cacheline-overlap tracking is meaningful for @dev. + * + * Mirrors the suppression conditions add_dma_entry() already applies to + * the sibling "cacheline tracking EEXIST" err_printk: + * + * - On architectures with hardware DMA cache coherence + * (dma_get_cache_alignment() < L1_CACHE_BYTES, e.g. x86_64) bus + * snooping makes overlapping cacheline mappings safe. + * + * - With CONFIG_DMA_BOUNCE_UNALIGNED_KMALLOC and an active SWIOTLB, + * unaligned kmalloc buffers are bounced through aligned swiotlb + * buffers, so the original cacheline overlap never reaches DMA. + * See commit 03521c892bb8 ("dma-debug: don't report false positives + * with DMA_BOUNCE_UNALIGNED_KMALLOC"). + * + * In both cases tracking is pure overhead and produces false-positive + * WARN_ONCEs. + */ +static bool dma_debug_cacheline_tracking_needed(struct device *dev) +{ + if (dma_get_cache_alignment() < L1_CACHE_BYTES) + return false; + if (IS_ENABLED(CONFIG_DMA_BOUNCE_UNALIGNED_KMALLOC) && + is_swiotlb_active(dev)) + return false; + return true; +} + static int active_cacheline_insert(struct dma_debug_entry *entry, bool *overlap_cache_clean) { @@ -490,6 +519,9 @@ static int active_cacheline_insert(struct dma_debug_ent= ry *entry, if (entry->direction =3D=3D DMA_TO_DEVICE) return 0; =20 + if (!dma_debug_cacheline_tracking_needed(entry->dev)) + return 0; + spin_lock_irqsave(&radix_lock, flags); rc =3D radix_tree_insert(&dma_active_cacheline, cln, entry); if (rc =3D=3D -EEXIST) { @@ -516,6 +548,9 @@ static void active_cacheline_remove(struct dma_debug_en= try *entry) if (entry->direction =3D=3D DMA_TO_DEVICE) return; =20 + if (!dma_debug_cacheline_tracking_needed(entry->dev)) + return; + spin_lock_irqsave(&radix_lock, flags); /* since we are counting overlaps the final put of the * cacheline will occur when the overlap count is 0. --=20 2.54.0