From nobody Wed Apr 1 12:32:24 2026 Received: from mail-lj1-f173.google.com (mail-lj1-f173.google.com [209.85.208.173]) (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 BDC2538737F for ; Tue, 31 Mar 2026 06:17:03 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.208.173 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774937826; cv=none; b=Fun0DKgjE+tW92iYZB9ATTGKVGbYe0ApHY++L0AlkjTgNogNSWXDkjN6UER82E5blhLO+gWKqD2FgYNNRv3+PenHaAPvm025y0vyFs0ySNE5Xya6BAk2kvJ+LNeHhItoNN5fL7s/i5aQ5RIDahWafJ5ALe9xDKYJgBYuEGel760= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774937826; c=relaxed/simple; bh=32Nkju6QPo7DcDfAct7IAD8EQeQKUz1dOWtW6JHOpPk=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=IT2EEaQeAakoDwG+8u85C/K64b3GAYON8tWkbG6+Fzfoaw1Xx+Nw/H4XQ+M8enTAC7QtfcpVLDK9b7PqmFPGRmAD28RB+iIPDxEqHPoV82LaCWysKoYPHXkncpT4Ayin7tOG46b2nlznyrAMHfTK3m6Gj3lFvqCFRIfFGCGFppQ= 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=P/dPmRFB; arc=none smtp.client-ip=209.85.208.173 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="P/dPmRFB" Received: by mail-lj1-f173.google.com with SMTP id 38308e7fff4ca-38c688bdc71so36265961fa.2 for ; Mon, 30 Mar 2026 23:17:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1774937822; x=1775542622; 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=slrIynpsyCDGbw/DVJ139y58tD8HDF7VkYtGZ4Dd10U=; b=P/dPmRFBIohgW+J1TbSt/GE0XAz0coqH2iZXs2lf31kShRPnxveKhLhjnVtYaAMRmP ekQ+yBAxsKy/D4NpGexvd9aIl8hndoaQnUwSyq9OM95X5c2OnhfDT/BegYZ50cfzANPy W21i3Id2f0l9Ar6gpzFX0EsCcZc1iD7d6Svpw7/9sZzTwn+5TQn/KCtxFF5xSzEel+1Q K5ERR+HkEbnasS0hFmbw6f7Ke/r/umNNifE7Mtd7b+Qd4zd981TvRGztvIF/yjfTL/A+ wmbRNuX/fpBdEaoa3f4+bdar5M/B9y0Npq05VkBRcPlgG7dzQy0R1hwH/DCHzeDFaEJ2 Cu+w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1774937822; x=1775542622; 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=slrIynpsyCDGbw/DVJ139y58tD8HDF7VkYtGZ4Dd10U=; b=i8C3UOWYZEpqsmwhnjSRucDNyDNAekL6dljD7tbwRdshuPfXgMvcemCIRjzhMsf3VY yq/mwGNgHr/5LrfvKHJx+7+5HkvRS+gYfGXbEv0Bg5ZAAGxZ0janhJFZRMCJClNJT2wL jbe1ijIpZTLP2Af98yTOZuJG3jnMLlAR8Mv74LmP7ni/VVIvN2GdJfd6bS6Z1+Oujx0C jTaLsb9i4bpyuBu30YH/k7PiHBN5yzTqZUHosH6mmQV8sz9rk543kll1oHS8FFxhva82 LMGA9gDdOoGU6LQsG6wHq0KNKKKkPD85BbIo1+JKc0UICmfkr14VraxzvcKZ3Qf+lNmS eVlg== X-Forwarded-Encrypted: i=1; AJvYcCUTr84leVrPImV3q02LNA5gS01fwJEKHWVFbaBTE3cYSChYbDEuM2Bu6o8OM4+2bQ4Y6RyTxiSDlbxEjHo=@vger.kernel.org X-Gm-Message-State: AOJu0YxQjBYshr+vPNmZFe+j1iH1YoeXO/fuLXYUWVnypot0Mmh8dCdS k95ZS9jpkeZUq3hQ/stDR9lh13s01wQvrGZVhGE5y05Pk2NC6ZNEeSrd X-Gm-Gg: ATEYQzw+ezobmmmJy4yGt+WVzyo4jPW6K/laXiFqHTIydn6QyuMTse/llMsnuRWEpfh Hr27spgkxRLKX3O2lqeRlwxFK31uFa1KNONF+t0LZrZRnXVhuNdqHBRyeQhWdcfLvwH8g1YTtJs 6yrOpOHQAudgtH+mNtt3yy4CM3SSnAR32axnhgee+sN4B2y4Q8r0SrUGA7ftPuMbz6qasypasUA jHgRY8woIH+MLwmalnX1t4t++JuA7luGDDenFmJioL2FBlFqGkEF+nWHD8vRLwrPdzDIBUsLa1L mKTwjE0ncJgrWiYB8L8+j8meyXoL7Yagq25/UTIS82OIwQ5+lDOEjjp9qzUatoOY74FhqjtueD0 VhJEW0rtB5DRLvrC6JKI/n5Ce9NXr5kb6xVjiIv3y63C3/M5NB+HJmdU90VNy0a54SYjW5t+Nyv 04C+kkV5uRNpUtTi+5TBqRqfKMrEc5Gckk8w== X-Received: by 2002:a05:6512:3b2c:b0:5a2:b3fc:b877 with SMTP id 2adb3069b0e04-5a2b3fcbaacmr2578412e87.25.1774937821564; Mon, 30 Mar 2026 23:17:01 -0700 (PDT) Received: from localhost ([188.234.148.119]) by smtp.gmail.com with ESMTPSA id 2adb3069b0e04-5a2b1455e14sm2145277e87.64.2026.03.30.23.17.00 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 30 Mar 2026 23:17:00 -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 v2] dma-buf/udmabuf: skip redundant cpu sync to fix cacheline EEXIST warning Date: Tue, 31 Mar 2026 11:16:57 +0500 Message-ID: <20260331061657.79983-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 Acked-by: Vivek Kasireddy --- v1 -> v2: - Rebased on drm-tip to resolve conflict with folio conversion patches. No code change, same two-line fix. v1: https://lore.kernel.org/all/20260317053653.28888-1-mikhail.v.gavrilov@g= mail.com/ 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 94b26ea706a3..bced421c0d65 100644 --- a/drivers/dma-buf/udmabuf.c +++ b/drivers/dma-buf/udmabuf.c @@ -145,7 +145,7 @@ static struct sg_table *get_sg_table(struct device *dev= , struct dma_buf *buf, if (ret < 0) goto err_alloc; =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; @@ -160,7 +160,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