From: Ahmad Fatoum <a.fatoum@pengutronix.de>
To: barebox@lists.infradead.org
Cc: jmaselbas@zdiv.net, ore@pengutronix.de,
Ahmad Fatoum <a.fatoum@pengutronix.de>
Subject: [PATCH master 1/2] mci: sdhci: unmap the DMA buffers actually used
Date: Mon, 11 Sep 2023 14:11:55 +0200 [thread overview]
Message-ID: <20230911121156.2632668-2-a.fatoum@pengutronix.de> (raw)
In-Reply-To: <20230911121156.2632668-1-a.fatoum@pengutronix.de>
At the end of sdhci_transfer_data_dma, sdhci_set_sdma_addr is called to
set the next DMA address. Recently, the computation of the next DMA
address was changed and instead of storing the next SDMA address into a
dedicated local variable as before, it was stored into the existing `dma'
variable. The dma variable is passed later though to dma_unmap_single(),
so clobbering it results in a loss of cache coherency and thus potential
memory corruption.
It's worth noting that this next SDMA address is not actually used for
DMA: Like Linux, barebox doesn't make use of this feature to chain (?) DMA
requests, so we actually invalidated memory buffers that were never used
for DMA.
Fixes: 76aa243aad95 ("mci: sdhci: Add 64-bit DMA addressing suport for V4 mode")
Fixes: 88f101358167 ("mci: sdhci: Force DMA update to the next block boundary")
Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de>
---
drivers/mci/sdhci.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/mci/sdhci.c b/drivers/mci/sdhci.c
index 9829a78cb6c5..ef36a9c1b38a 100644
--- a/drivers/mci/sdhci.c
+++ b/drivers/mci/sdhci.c
@@ -295,14 +295,14 @@ int sdhci_transfer_data_dma(struct sdhci *sdhci, struct mci_data *data,
int boundary_cfg = (sdhci->sdma_boundary >> 12) & 0x7;
dma_addr_t boundary_size = 4096 << boundary_cfg;
/* Force update to the next DMA block boundary. */
- dma = (dma & ~(boundary_size - 1)) + boundary_size;
+ dma_addr_t next = (dma & ~(boundary_size - 1)) + boundary_size;
/*
* DMA engine has stopped on buffer boundary. Acknowledge
* the interrupt and kick the DMA engine again.
*/
sdhci_write32(sdhci, SDHCI_INT_STATUS, SDHCI_INT_DMA);
- sdhci_set_sdma_addr(sdhci, dma);
+ sdhci_set_sdma_addr(sdhci, next);
}
if (irqstat & SDHCI_INT_XFER_COMPLETE)
--
2.39.2
next prev parent reply other threads:[~2023-09-11 12:13 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-09-11 12:11 [PATCH master 0/2] mci: sdhci: fix memory corruption on DMA Ahmad Fatoum
2023-09-11 12:11 ` Ahmad Fatoum [this message]
2023-09-11 12:11 ` [PATCH master 2/2] mci: sdhci: hardcode SDMA boundary for DMA Ahmad Fatoum
2023-09-12 9:19 ` [PATCH master 0/2] mci: sdhci: fix memory corruption on DMA Sascha Hauer
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=20230911121156.2632668-2-a.fatoum@pengutronix.de \
--to=a.fatoum@pengutronix.de \
--cc=barebox@lists.infradead.org \
--cc=jmaselbas@zdiv.net \
--cc=ore@pengutronix.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