| Message ID | 20260705075738.10639-1-zenghongling@kylinos.cn (mailing list archive) |
|---|---|
| State | New |
| Headers |
Return-Path: <linux-sunxi+bounces-24166-sunxi=pue.re@lists.linux.dev> X-Original-To: noreply@patchwork.local Delivered-To: noreply@patchwork.local Received: from sea.lore.kernel.org (sea.lore.kernel.org [172.234.253.10]) by mxe881.netcup.net (Postfix) with ESMTPS id DB5561C3FF9 for <noreply@patchwork.local>; Sun, 5 Jul 2026 09:57:59 +0200 (CEST) Authentication-Results: mxe881; spf=pass (sender IP is 172.234.253.10) smtp.mailfrom=linux-sunxi+bounces-24166-noreply=patchwork.local@lists.linux.dev smtp.helo=sea.lore.kernel.org Received-SPF: pass (mxe881: domain of lists.linux.dev designates 172.234.253.10 as permitted sender) client-ip=172.234.253.10; envelope-from=linux-sunxi+bounces-24166-noreply=patchwork.local@lists.linux.dev; helo=sea.lore.kernel.org; Received: from smtp.subspace.kernel.org (conduit.subspace.kernel.org [100.90.174.1]) by sea.lore.kernel.org (Postfix) with ESMTP id 4E80130056C4 for <noreply@patchwork.local>; Sun, 5 Jul 2026 07:57:57 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id CB64635E1D5; Sun, 5 Jul 2026 07:57:56 +0000 (UTC) X-Original-To: linux-sunxi@lists.linux.dev Received: from mailgw.kylinos.cn (mailgw.kylinos.cn [124.126.103.232]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 2158E18859B for <linux-sunxi@lists.linux.dev>; Sun, 5 Jul 2026 07:57:52 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=124.126.103.232 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783238276; cv=none; b=OLeENynl9QIytSfBGX9Cr1hjhGT1axuGiNj8HxVamSqBfPgDILGI6a/trLH47oQuvH0Ee6sTEuKh9JQUMv6Am5aO8PMbBUCLGVECc7kc2md7y7Lcgppw6E52CjK3JTvwvFhmFY4IAwE3toXge+oFr21hSIEzBQK5Xqo5mTX5ynE= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783238276; c=relaxed/simple; bh=tFeesKG8XuVOwny1VBR+fnpr3ScvxX6H341Mpa6xfws=; h=From:To:Cc:Subject:Date:Message-Id:MIME-Version; b=n6FycsAE+bulippgwUyIPiZ8Aq8CnqAosLjxcQ0DuSnE3frm0cb1JDqq32JcV3YpirCc8Rsohw9xlqqjeZkUrX1xiJUmRZAJP+O44iRfDMP0INz2jTDBGqf6ZRiEeOq+GArcpTIZFfND6QxsafnY7TM29CrLLHwfE0KuY4vFBfw= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=kylinos.cn; spf=pass smtp.mailfrom=kylinos.cn; arc=none smtp.client-ip=124.126.103.232 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=kylinos.cn Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=kylinos.cn X-UUID: 3353b854784711f1aa26b74ffac11d73-20260705 X-CID-P-RULE: Release_Ham X-CID-O-INFO: VERSION:1.3.12,REQID:a6fc6c02-e40b-4e53-b58f-7af923fdfb6f,IP:0,U RL:0,TC:0,Content:-5,EDM:-25,RT:0,SF:0,FILE:0,BULK:0,RULE:Release_Ham,ACTI ON:release,TS:-30 X-CID-META: VersionHash:e7bac3a,CLOUDID:c97a6a94ed67e26f58b4136fe0846417,BulkI D:nil,BulkQuantity:0,Recheck:0,SF:102|850|865|898,TC:nil,Content:0|15|50,E DM:2,IP:nil,URL:0,File:nil,RT:nil,Bulk:nil,QS:nil,BEC:nil,COL:0,OSI:0,OSA: 0,AV:0,LES:1,SPR:NO,DKR:0,DKP:0,BRR:0,BRE:0,ARC:0 X-CID-BVR: 2,SSN|SDN X-CID-BAS: 2,SSN|SDN,0,_ X-CID-FACTOR: TF_CID_SPAM_SNR X-CID-RHF: D41D8CD98F00B204E9800998ECF8427E X-UUID: 3353b854784711f1aa26b74ffac11d73-20260705 X-User: zenghongling@kylinos.cn Received: from localhost.localdomain [(10.44.16.150)] by mailgw.kylinos.cn (envelope-from <zenghongling@kylinos.cn>) (Generic MTA with TLSv1.3 TLS_AES_256_GCM_SHA384 256/256) with ESMTP id 1267926036; Sun, 05 Jul 2026 15:57:42 +0800 From: Hongling Zeng <zenghongling@kylinos.cn> To: vkoul@kernel.org, Frank.Li@kernel.org, wens@kernel.org, jernej.skrabec@gmail.com, samuel@sholland.org Cc: dmaengine@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-sunxi@lists.linux.dev, linux-kernel@vger.kernel.org, zhongling0719@126.com, Hongling Zeng <zenghongling@kylinos.cn>, stable@vger.kernel.org Subject: [PATCH] dmaengine: sun6i: Fix potential deadlock in sun6i_dma_terminate_all() Date: Sun, 5 Jul 2026 15:57:38 +0800 Message-Id: <20260705075738.10639-1-zenghongling@kylinos.cn> X-Mailer: git-send-email 2.25.1 Precedence: bulk X-Mailing-List: linux-sunxi@lists.linux.dev List-Id: <linux-sunxi.lists.linux.dev> List-Subscribe: <mailto:linux-sunxi+subscribe@lists.linux.dev> List-Unsubscribe: <mailto:linux-sunxi+unsubscribe@lists.linux.dev> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Rspamd-Server: rspamd-worker-8404 X-Spamd-Result: default: False [-0.66 / 15.00]; BAYES_HAM(-5.50)[99.99%]; RBL_SENDERSCORE(2.00)[172.234.253.10:from]; SUSPICIOUS_RECIPS(1.50)[]; MID_CONTAINS_FROM(1.00)[]; R_MISSING_CHARSET(0.50)[]; MAILLIST(-0.15)[generic]; BAD_REP_POLICIES(0.10)[]; MIME_GOOD(-0.10)[text/plain]; HAS_LIST_UNSUB(-0.01)[]; DMARC_NA(0.00)[kylinos.cn]; DBL_BLOCKED_OPENRESOLVER(0.00)[sea.lore.kernel.org:rdns,sea.lore.kernel.org:helo,kylinos.cn:email]; TAGGED_RCPT(0.00)[]; RCPT_COUNT_TWELVE(0.00)[12]; FREEMAIL_CC(0.00)[vger.kernel.org,lists.infradead.org,lists.linux.dev,126.com,kylinos.cn]; FUZZY_BLOCKED(0.00)[rspamd.com]; PRECEDENCE_BULK(0.00)[]; FROM_HAS_DN(0.00)[]; FORGED_SENDER_MAILLIST(0.00)[]; FORGED_RECIPIENTS_MAILLIST(0.00)[]; RCVD_TLS_LAST(0.00)[]; FREEMAIL_TO(0.00)[kernel.org,gmail.com,sholland.org]; R_SPF_ALLOW(0.00)[+ip4:172.234.253.10]; ARC_ALLOW(0.00)[subspace.kernel.org:s=arc-20240116:i=1]; R_DKIM_NA(0.00)[]; TAGGED_FROM(0.00)[bounces-24166-noreply=patchwork.local]; RCVD_COUNT_FIVE(0.00)[5]; MIME_TRACE(0.00)[0:+]; FROM_NEQ_ENVFROM(0.00)[zenghongling@kylinos.cn,linux-sunxi@lists.linux.dev]; ASN(0.00)[asn:63949, ipnet:172.234.224.0/19, country:SG]; TO_DN_SOME(0.00)[] X-Rspamd-Queue-Id: DB5561C3FF9 X-MORS-Enabled: yes X-MORS-DOMAIN: patchwork.local X-MORS-HOSTING: hosting172546 X-MORS-USER: hosting172546 X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= |
| Series |
dmaengine: sun6i: Fix potential deadlock in sun6i_dma_terminate_all()
|
|
Commit Message
Hongling Zeng
July 5, 2026, 7:57 a.m. UTC
sun6i_dma_terminate_all() acquires sdev->lock with plain spin_lock()
from process context. Since interrupts remain enabled, a DMA interrupt
can fire on the same CPU while the lock is held. The interrupt handler
schedules sun6i_dma_tasklet(), which attempts to acquire the same lock
with spin_lock_irq(), causing a deadlock.
Fix by using spin_lock_irq() to disable interrupts while holding
sdev->lock, consistent with other call sites.
Fixes: ba489fd46ab6 ("dmaengine: sun6i: Add support for Allwinner A31 DMA controller")
Cc: stable@vger.kernel.org
Signed-off-by: Hongling Zeng <zenghongling@kylinos.cn>
---
drivers/dma/sun6i-dma.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
Comments
Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider: New issues: - [High] Unconditional hardware interrupt re-enablement violates caller lock state. Pre-existing issues: - [High] Incomplete deadlock fix: sun6i_dma_pause() contains the exact same deadlock vulnerability. - [High] Lockless read of vchan->phy causes Time-Of-Check to Time-Of-Use (TOCTOU) race condition and hardware corruption. -- commit 1435f9b5204cbc43aa5b41f133e1e3e88387cce1 Author: Hongling Zeng <zenghongling@kylinos.cn> dmaengine: sun6i: Fix potential deadlock in sun6i_dma_terminate_all() This commit modifies sun6i_dma_terminate_all() to use spin_lock_irq() instead of plain spin_lock() when acquiring sdev->lock. The change aims to prevent a deadlock caused when a DMA interrupt fires while the lock is held. > diff --git a/drivers/dma/sun6i-dma.c b/drivers/dma/sun6i-dma.c > index a9a254dbf8cb9..840f7276ad5d5 100644 > --- a/drivers/dma/sun6i-dma.c > +++ b/drivers/dma/sun6i-dma.c > @@ -939,9 +939,9 @@ static int sun6i_dma_terminate_all(struct dma_chan *chan) > unsigned long flags; > LIST_HEAD(head); > [Severity: High] This is a pre-existing issue, but does reading vchan->phy locklessly at the start of this function create a race condition? In sun6i_dma_terminate_all(): static int sun6i_dma_terminate_all(struct dma_chan *chan) { ... struct sun6i_pchan *pchan = vchan->phy; ... spin_lock_irqsave(&vchan->vc.lock, flags); ... if (pchan) { writel(DMA_CHAN_ENABLE_STOP, pchan->base + DMA_CHAN_ENABLE); If sun6i_dma_tasklet() completes a transfer, clears vchan->phy, and reassigns the physical channel to a different virtual channel before the lock is acquired here, would this operate on a stale pchan and stop an unrelated transfer? Similar lockless reads of vchan->phy exist in sun6i_dma_pause(), sun6i_dma_resume(), and sun6i_dma_tx_status(). > - spin_lock(&sdev->lock); > + spin_lock_irq(&sdev->lock); > list_del_init(&vchan->node); > - spin_unlock(&sdev->lock); [Severity: High] Does this unconditional spin_unlock_irq() risk breaking callers that invoke dmaengine_terminate_all() with interrupts already disabled? Since spin_unlock_irq() forces hardware interrupts back on, it could destroy the caller's interrupt-disabled state and lead to unexpected nested interrupts. Is it safer to use spin_lock_irqsave() and spin_unlock_irqrestore() here? [Severity: High] This is a pre-existing issue, but does sun6i_dma_pause() have the exact same deadlock vulnerability being fixed here? sun6i_dma_pause() acquires the same lock without disabling interrupts: static int sun6i_dma_pause(struct dma_chan *chan) { ... } else { spin_lock(&sdev->lock); list_del_init(&vchan->node); spin_unlock(&sdev->lock); } Could a DMA interrupt fire while this lock is held in process context and cause the same tasklet deadlock? > > spin_lock_irqsave(&vchan->vc.lock, flags); >
diff --git a/drivers/dma/sun6i-dma.c b/drivers/dma/sun6i-dma.c index a9a254dbf8cb..840f7276ad5d 100644 --- a/drivers/dma/sun6i-dma.c +++ b/drivers/dma/sun6i-dma.c @@ -939,9 +939,9 @@ static int sun6i_dma_terminate_all(struct dma_chan *chan) unsigned long flags; LIST_HEAD(head); - spin_lock(&sdev->lock); + spin_lock_irq(&sdev->lock); list_del_init(&vchan->node); - spin_unlock(&sdev->lock); + spin_unlock_irq(&sdev->lock); spin_lock_irqsave(&vchan->vc.lock, flags);