From: Marek Szyprowski <m.szyprowski@samsung.com>
To: linux-mips@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
iommu@lists.linux.dev, linux-kernel@vger.kernel.org
Cc: Marek Szyprowski <m.szyprowski@samsung.com>,
Robin Murphy <robin.murphy@arm.com>,
Christoph Hellwig <hch@infradead.org>,
Thomas Bogendoerfer <tsbogend@alpha.franken.de>,
Madhavan Srinivasan <maddy@linux.ibm.com>,
Michael Ellerman <mpe@ellerman.id.au>,
Nicholas Piggin <npiggin@gmail.com>,
"Christophe Leroy (CS GROUP)" <chleroy@kernel.org>,
"Ritesh Harjani (IBM)" <ritesh.list@gmail.com>,
Shrikanth Hegde <sshegde@linux.ibm.com>,
Chris Zankel <chris@zankel.net>,
Max Filippov <jcmvbkbc@gmail.com>
Subject: [PATCH/RFC 1/7] xtensa: write back dirty lines in arch_dma_prep_coherent()
Date: Fri, 6 Nov 2026 23:56:21 +0100 [thread overview]
Message-ID: <20261106225628.215319-2-m.szyprowski@samsung.com> (raw)
In-Reply-To: <20261106225628.215319-1-m.szyprowski@samsung.com>
arch_dma_prep_coherent() is expected to remove any dirty cache lines
covering the buffer, so that they are neither lost nor evicted later on
top of data written through the uncached alias or by the device.
xtensa implements it with __invalidate_dcache_range(), which uses the
DHI instruction and discards dirty lines without writing them back.
This loses data written through the cached kernel mapping right before
the call. dma_direct_alloc() zeroes the buffer with memset() on the
cached linear mapping and only then calls arch_dma_prep_coherent() and
switches to the KSEG bypass alias via arch_dma_set_uncached(). On cores
with a write-back data cache the zeroes still sitting in the cache are
dropped, and dma_alloc_coherent() returns a buffer with stale content.
The same applies to dma_direct_alloc_no_mapping(), which allocates the
pages with __GFP_ZERO before calling arch_dma_prep_coherent().
Use __flush_invalidate_dcache_range() (DHWBI) instead, which writes the
dirty lines back before invalidating them. On cores with a write-through
data cache it maps to __invalidate_dcache_range(), so nothing changes
there.
Fixes: 0f665b9e2a6d ("xtensa: use the generic uncached segment support")
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
---
arch/xtensa/kernel/pci-dma.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/xtensa/kernel/pci-dma.c b/arch/xtensa/kernel/pci-dma.c
index 94955caa4488..e1c00ec37eed 100644
--- a/arch/xtensa/kernel/pci-dma.c
+++ b/arch/xtensa/kernel/pci-dma.c
@@ -82,7 +82,7 @@ void arch_sync_dma_for_device(phys_addr_t paddr, size_t size,
void arch_dma_prep_coherent(struct page *page, size_t size)
{
- __invalidate_dcache_range((unsigned long)page_address(page), size);
+ __flush_invalidate_dcache_range((unsigned long)page_address(page), size);
}
/*
--
2.43.0
next prev parent reply other threads:[~2026-11-06 22:56 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CGME20261106225648eucas1p27da7cef5cdecc76ee6a3e0c1f0a20dfc@eucas1p2.samsung.com>
2026-11-06 22:56 ` [PATCH/RFC 0/7] dma-mapping: DMA_ATTR_NO_KERNEL_MAPPING related fixes Marek Szyprowski
[not found] ` <CGME20261106225649eucas1p27f1d64162099ef1c7472469f2a33201e@eucas1p2.samsung.com>
2026-11-06 22:56 ` Marek Szyprowski [this message]
[not found] ` <CGME20261106225650eucas1p1ad152cf3818ff46576dca66fd621fd88@eucas1p1.samsung.com>
2026-11-06 22:56 ` [PATCH/RFC 2/7] xtensa: handle highmem pages in arch_dma_prep_coherent() Marek Szyprowski
[not found] ` <CGME20261106225650eucas1p1efb74e6071ef81de13ca8e1e67d83655@eucas1p1.samsung.com>
2026-11-06 22:56 ` [PATCH/RFC 3/7] MIPS: mm: " Marek Szyprowski
[not found] ` <CGME20261106225651eucas1p2d038403b190875c1dd698da959eefbd3@eucas1p2.samsung.com>
2026-11-06 22:56 ` [PATCH/RFC 4/7] powerpc/mm: " Marek Szyprowski
[not found] ` <CGME20261106225652eucas1p2d4da27e923c75a7460861531bb01b60e@eucas1p2.samsung.com>
2026-11-06 22:56 ` [PATCH/RFC 5/7] dma-mapping: document that arch_dma_prep_coherent() must handle highmem Marek Szyprowski
[not found] ` <CGME20261106225653eucas1p1f4445ad04b7eb455ba1bcd7992143694@eucas1p1.samsung.com>
2026-11-06 22:56 ` [PATCH/RFC 6/7] dma-direct: do not skip cache maintenance for highmem pages in no-mapping allocations Marek Szyprowski
[not found] ` <CGME20261106225654eucas1p22d7e8c8769d952eef8a7c2cb15923e3c@eucas1p2.samsung.com>
2026-11-06 22:56 ` [PATCH/RFC 7/7] dma-direct: zero memory allocated with DMA_ATTR_NO_KERNEL_MAPPING Marek Szyprowski
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20261106225628.215319-2-m.szyprowski@samsung.com \
--to=m.szyprowski@samsung.com \
--cc=chleroy@kernel.org \
--cc=chris@zankel.net \
--cc=hch@infradead.org \
--cc=iommu@lists.linux.dev \
--cc=jcmvbkbc@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mips@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=maddy@linux.ibm.com \
--cc=mpe@ellerman.id.au \
--cc=npiggin@gmail.com \
--cc=ritesh.list@gmail.com \
--cc=robin.murphy@arm.com \
--cc=sshegde@linux.ibm.com \
--cc=tsbogend@alpha.franken.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®