From nobody Tue Apr 7 01:03:22 2026 Received: from mail-lf1-f43.google.com (mail-lf1-f43.google.com [209.85.167.43]) (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 D1CFD37F001 for ; Tue, 17 Mar 2026 05:37:03 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.167.43 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773725825; cv=none; b=rItICDu3GAO2S26STO50J2MN5jyAnJMJjK5jPWNUSrhWaXIO4CaI1oOjZQN4GrlKKdLSzL5teIQvvyN2p3M/pf4glVNsEITJP2b6IHsM8BTWrEPManmHoPSYKTNBSaDs0OcbWascG/FaVDqCA13WWPAn9UkHrgtT/aKTnwgeD9U= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773725825; c=relaxed/simple; bh=GxQU1VRrYRoTgEMwUUU2mm0qyNrjehpCX0AAPIFbHH0=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=Al+fNsDoYqw/U61s2VfJBdzwhvqYfC9v4cuIG+ofvUmsCYIOHptGLrEGxnhIQgHmAXrJsJ1doaulXjwk4OZX53DJ53HCkwM9JndoDDJ+atee5brgQvVH+zJ2MUhcm1K6gYyM70014eLBZ6IWkYr0PejFGO/4o7h+wmilLDWMKgY= 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=OdOt05lH; arc=none smtp.client-ip=209.85.167.43 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="OdOt05lH" Received: by mail-lf1-f43.google.com with SMTP id 2adb3069b0e04-5a12cd0bcd8so6131440e87.3 for ; Mon, 16 Mar 2026 22:37:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1773725822; x=1774330622; 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=2NiRAQv05vxst//6uLfp/yYFASGq0d9XovqJe++xcxQ=; b=OdOt05lHxGWg/gkvUpH+ItKSO494Xz9SfA2B3Ljhl5zGJyjtsgTkniIdCbAJF+MPcX IvhR+Gedu+wSCPxqdJB5QQDEHeCD8RjHjE0T7O69qbHvKdgDa8+42Z/Z4KrulFtIoB/A utRMtx3b36m/NUmoTif/d/VDP5d+fuTaWeuemjRImCPD4KMAp5/JCEo2XW4i8UUTZ0uc Lql07SfF9PonCAskYOki3fme8O0WZkOR9BJYXatgeoknwNVQZaXa9/3LndeDCqtJfr9j 1okDnOTRNNoToBIuRjrSt5B6nLDAio8TzT30N1jvtIk4gh0mYdp6EzCQTZRlCc3K/6ZI 9mUQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1773725822; x=1774330622; 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=2NiRAQv05vxst//6uLfp/yYFASGq0d9XovqJe++xcxQ=; b=AL8txCyJS++7fb7n+H2XNw/gaqpWoSOSG8fmT7ETboRjTXJlKDktMDKz8mrGrNRjgF +MjUUo4PGGfYnXjr5w4E0dUDal+xhrv8h4SJrGSikVX8pRxlwOaPTJVBChq5gpKUhbaR dicPpjSQZQDsJTFeFApzmRANuHQKgd0z8KO0JRShAbRGdSu9W0xXCfItzHn1IiCFNkUD GTByQQnhwjcDqRrYvvKOPMMuy781knFWqvXpLsSkkVi160Ec+vsP2YFa1cTIEW/43iwW sQ6cR7qqfwjiwYgbkZgIXt1XkxH2/qygPogA2lcqsR7XbEg7g4E8LBJRsDnWZDVzq5ag pWQg== X-Forwarded-Encrypted: i=1; AJvYcCUxAOAzRcq4wz4OFXGV7WFa6jzYGdVj/q/NkaUu7nDYU9P0Uobcule2gASwpBjRFnjgtCWvm0ISET4WUuI=@vger.kernel.org X-Gm-Message-State: AOJu0Yz2TNIHn4mMCkfSt5+RFv3Hg/tdsbfn1PNzCGTjTHCl5CLZWO32 7YpPp9CGjg549gJCTi03OS+4pdZ/kGgVmZ7dY4CJHpAvWkB7/RuZCJxa X-Gm-Gg: ATEYQzyrk7udJJJvNE+EvSSWKewTsSuvUuoTYTO9+z1XgU+uf6W15r1sMK4qgvGQcCP cayC7PsvVzQ0j0723FB2EhoEnlhXXi+/P+lCSVrZl8mbzxz4DQQr7BhAWtSMyGpocv8+aNIwnQb 5YCf13mP/q+Y5X1ERWlI2CDcwIdHpAw1J2oGPkXYoe41LPiMV938UAexMk75XDDdIzh/ADguP7x 8mdypv43ynF1a7uOLAgtLpMWT5uCQRxkV2NrmvKbrb69Ca2R9VKtBDBQcaZdcElke7hYVcdP/ge GStE/O8wgeQTVmqsAVLxMA4k2oAjtJpuOD43/ICEo2oBOAvMtozx2RZGNmoaktNJuM5oHBpr5sM YMoIIWuykJV0jOtZg9C/IGM/1dt4X66MUY+O35mvtQvhV7dKgY6ui8uiTH06mAAM4nsi5FpPRl+ ESqcvHNZFPOMLg4wG6FcTi//+LS9CMzhThk2O83TaUoRsa X-Received: by 2002:a05:6512:2350:b0:5a1:c03b:7980 with SMTP id 2adb3069b0e04-5a1c03b7a7dmr186889e87.28.1773725821391; Mon, 16 Mar 2026 22:37:01 -0700 (PDT) Received: from localhost ([188.234.148.119]) by smtp.gmail.com with ESMTPSA id 2adb3069b0e04-5a156366606sm3958338e87.73.2026.03.16.22.36.59 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 16 Mar 2026 22:36:59 -0700 (PDT) From: Mikhail Gavrilov To: kraxel@redhat.com, vivek.kasireddy@intel.com Cc: sumit.semwal@linaro.org, christian.koenig@amd.com, dri-devel@lists.freedesktop.org, linux-media@vger.kernel.org, linaro-mm-sig@lists.linaro.org, linux-kernel@vger.kernel.org, stable@vger.kernel.org, Mikhail Gavrilov Subject: [PATCH] dma-buf/udmabuf: skip redundant cpu sync to fix cacheline EEXIST warning Date: Tue, 17 Mar 2026 10:36:53 +0500 Message-ID: <20260317053653.28888-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_SG is enabled, importing a udmabuf into a DRM driver (e.g. amdgpu for video playback in GNOME Videos / Showtime) triggers a spurious warning: DMA-API: amdgpu 0000:03:00.0: cacheline tracking EEXIST, \ overlapping mappings aren't supported WARNING: kernel/dma/debug.c:619 at add_dma_entry+0x473/0x5f0 The call chain is: amdgpu_cs_ioctl -> amdgpu_ttm_backend_bind -> dma_buf_map_attachment -> [udmabuf] map_udmabuf -> get_sg_table -> dma_map_sgtable(dev, sg, direction, 0) // attrs=3D0 -> debug_dma_map_sg -> add_dma_entry -> EEXIST This happens because udmabuf builds a per-page scatter-gather list via sg_set_folio(). When begin_cpu_udmabuf() has already created an sg table mapped for the misc device, and an importer such as amdgpu maps the same pages for its own device via map_udmabuf(), the DMA debug infrastructure sees two active mappings whose physical addresses share cacheline boundaries and warns about the overlap. The DMA_ATTR_SKIP_CPU_SYNC flag suppresses this check in add_dma_entry() because it signals that no CPU cache maintenance is performed at map/unmap time, making the cacheline overlap harmless. All other major dma-buf exporters already pass this flag: - drm_gem_map_dma_buf() passes DMA_ATTR_SKIP_CPU_SYNC - amdgpu_dma_buf_map() passes DMA_ATTR_SKIP_CPU_SYNC The CPU sync at map/unmap time is also redundant for udmabuf: begin_cpu_udmabuf() and end_cpu_udmabuf() already perform explicit cache synchronization via dma_sync_sgtable_for_cpu/device() when CPU access is requested through the dma-buf interface. Pass DMA_ATTR_SKIP_CPU_SYNC to dma_map_sgtable() and dma_unmap_sgtable() in udmabuf to suppress the spurious warning and skip the redundant sync. Fixes: 284562e1f348 ("udmabuf: implement begin_cpu_access/end_cpu_access ho= oks") Cc: stable@vger.kernel.org Signed-off-by: Mikhail Gavrilov --- drivers/dma-buf/udmabuf.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/dma-buf/udmabuf.c b/drivers/dma-buf/udmabuf.c index 94b8ecb892bb..9c6f8785a28a 100644 --- a/drivers/dma-buf/udmabuf.c +++ b/drivers/dma-buf/udmabuf.c @@ -162,7 +162,7 @@ static struct sg_table *get_sg_table(struct device *dev= , struct dma_buf *buf, sg_set_folio(sgl, ubuf->folios[i], PAGE_SIZE, ubuf->offsets[i]); =20 - ret =3D dma_map_sgtable(dev, sg, direction, 0); + ret =3D dma_map_sgtable(dev, sg, direction, DMA_ATTR_SKIP_CPU_SYNC); if (ret < 0) goto err_map; return sg; @@ -177,7 +177,7 @@ static struct sg_table *get_sg_table(struct device *dev= , struct dma_buf *buf, static void put_sg_table(struct device *dev, struct sg_table *sg, enum dma_data_direction direction) { - dma_unmap_sgtable(dev, sg, direction, 0); + dma_unmap_sgtable(dev, sg, direction, DMA_ATTR_SKIP_CPU_SYNC); sg_free_table(sg); kfree(sg); } --=20 2.53.0