linux-kernel - [PATCH 1/3] dmaengine: ti: k3-udma: Reduce completion polling delay

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <20250731-ti-dma-timeout-v1-1-33321d2b7406@bootlin.com>
Date: Thu, 31 Jul 2025 18:41:29 +0200
From: Miquel Raynal <miquel.raynal@...tlin.com>
To: Peter Ujfalusi <peter.ujfalusi@...il.com>, 
 Vinod Koul <vkoul@...nel.org>, Grygorii Strashko <grygorii.strashko@...com>
Cc: Thomas Petazzoni <thomas.petazzoni@...tlin.com>, 
 Peter Ujfalusi <peter.ujfalusi@...com>, dmaengine@...r.kernel.org, 
 linux-kernel@...r.kernel.org, Miquel Raynal <miquel.raynal@...tlin.com>, 
 stable@...r.kernel.org
Subject: [PATCH 1/3] dmaengine: ti: k3-udma: Reduce completion polling
 delay

DMA transfers may be slow if the peer device is slow (eg. a UART
controller, a SPI controller...). The completion worker is started very
early compared to the actual draining speed, leading to low speed
devices suffering from a full 1s delay before noticing the transfers are
done, further delaying the execution of their callback.

1s seems overly large for a polling delay, reduce it to arbitrarily
100us which is the minimum amount of time to transfer a byte (and see
some progress on the residue variable) on a 100kHz bus. Based on this
first measure, the next sleep will be much closer to what is actually
needed for the transfer to complete.

The 1 second polling delay involves that any device driver with a (very
standard) 1 second timeout will error out indicating a transfer error,
whereas the data has actually been transferred correctly.

Fixes: 25dcb5dd7b7c ("dmaengine: ti: New driver for K3 UDMA")
Cc: stable@...r.kernel.org # 5.7
Signed-off-by: Miquel Raynal <miquel.raynal@...tlin.com>
---
This issue has been observed by playing with the DMA controller on
Beagle Play.

The patch will not apply before v5.7 and probably do not need to be
backported before anyway.
---
 drivers/dma/ti/k3-udma.c | 17 ++++++++---------
 1 file changed, 8 insertions(+), 9 deletions(-)

diff --git a/drivers/dma/ti/k3-udma.c b/drivers/dma/ti/k3-udma.c
index aa2dc762140f6eee334f4506a592e72600ae9834..b2059baed1b2ffc81c10feca797c763e2a04a357 100644
--- a/drivers/dma/ti/k3-udma.c
+++ b/drivers/dma/ti/k3-udma.c
@@ -1115,19 +1115,18 @@ static void udma_check_tx_completion(struct work_struct *work)
 			time_diff = ktime_sub(uc->tx_drain.tstamp,
 					      time_diff) + 1;
 			residue_diff -= uc->tx_drain.residue;
+			/*
+			 * Try to guess when we should check next time by
+			 * calculating rate at which data is being drained at
+			 * the peer device. Slow devices might have not yet
+			 * started, showing no progress. Use an arbitrary delay
+			 * in this case.
+			 */
 			if (residue_diff) {
-				/*
-				 * Try to guess when we should check
-				 * next time by calculating rate at
-				 * which data is being drained at the
-				 * peer device
-				 */
 				delay = (time_diff / residue_diff) *
 					uc->tx_drain.residue;
 			} else {
-				/* No progress, check again in 1 second  */
-				schedule_delayed_work(&uc->tx_drain.work, HZ);
-				break;
+				delay = 100000;
 			}
 
 			spin_unlock_irqrestore(&uc->vc.lock, flags);

-- 
2.50.1