From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from m16.mail.163.com (m16.mail.163.com [220.197.31.3]) (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 CBE2433C1AD for ; Fri, 7 Aug 2026 15:12:32 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=220.197.31.3 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786115558; cv=none; b=oF3HfGlmsv2tj8zAW60LtNjrGAyQWPluNDnl7UBzcgpE/i41rK2wONG4iI6Q9JTP4+Xcmjx1SK0CupHEdpdtLjwcZ0YRQvjW+m8ASlTd5Sl6bO0MA8KrU6cVCY7+XXEvV0ASyzBf1h/oi41clhoy8fAai1TwELAa9dkm1aly0do= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786115558; c=relaxed/simple; bh=xAlgKOanZUO69crIf5zuK3Jgn+0S9XV3E+Q195wuKPg=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=UFhGRw6rIdiz0Q9NIDg4OHWT9O7zY4NS+wq3ZJCF2NyOeqFcpf10DJZf2lqA4/335CsZNP90fm1PUOtBFM48XRI09TNI1kWQ3XCgl4dvfYQtSRuKqvmeL1tvS61itXxTGih3l7j653SEOumVlOT3rCzhct4gif8Ht+FyGdV5zfo= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=163.com; spf=pass smtp.mailfrom=163.com; dkim=pass (1024-bit key) header.d=163.com header.i=@163.com header.b=Q5+hOW5b; arc=none smtp.client-ip=220.197.31.3 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=163.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=163.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=163.com header.i=@163.com header.b="Q5+hOW5b" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=163.com; s=s110527; h=From:To:Subject:Date:Message-ID:MIME-Version; bh=IO i80gEkYM4uCYQ1/ilhSdZhfEjteUdqJwxT+1+Y4ak=; b=Q5+hOW5bHEPF45VC9E CLuFGpNP1vh5huW4DQWktedM9B0wFzwuT5mg7PeeGkvrhWvXwjCkNuEz5bt1LWbV BgP+918a6Avap/TKHW/7ZtOVZCIddij2ezvv3qRxA4vQNcioqGsbXxmWCS4uiS74 xChi4hOQU16InFy6O0zJ5ukgI= Received: from localhost (unknown []) by gzga-smtp-mtada-g1-4 (Coremail) with SMTP id _____wA3v_+c9XVqE1XXOQ--.26426S2; Fri, 07 Aug 2026 23:11:24 +0800 (CST) From: Hui Su To: andy@kernel.org Cc: gregkh@linuxfoundation.org, namcao@linutronix.de, dri-devel@lists.freedesktop.org, linux-fbdev@vger.kernel.org, linux-staging@lists.linux.dev, linux-kernel@vger.kernel.org, sh_def@163.com, thomas.petazzoni@free-electrons.com, notro@tronnes.org Subject: [PATCH v2] staging: fbtft: make dirty_lock IRQ-safe Date: Fri, 7 Aug 2026 23:09:55 +0800 Message-ID: <20260807150953.2811933-3-sh_def@163.com> X-Mailer: git-send-email 2.43.0 Precedence: bulk X-Mailing-List: linux-staging@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-CM-TRANSID:_____wA3v_+c9XVqE1XXOQ--.26426S2 X-Coremail-Antispam: 1Uf129KBjvJXoWxGF15ZF48WF48urW8GFWkCrg_yoW5Zw15pa 17ta45Ar48Ga1Fvr43Gr4DZF1a939Fkr4qkry0kw1fZ3W3Crs7WrykJFyrX3W0yrZxtrn5 CrWrK34fJw4UCw7anT9S1TB71UUUUU7qnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDUYxBIdaVFxhVjvjDU0xZFpf9x0pRiYFJUUUUU= X-CM-SenderInfo: xvkbvvri6rljoofrz/xtbC6R2c+2p19Z08UwAA3L fbtft_mkdirty() can be reached from the fbcon rendering path while processing printk() in hardirq context. Meanwhile, dirty_lock is also taken by fbtft_deferred_io() in workqueue context with local interrupts enabled. Lockdep reports a possible IRQ lock inversion involving dirty_lock and console_owner. A hardirq can interrupt a CPU holding dirty_lock and enter the console rendering path, which can attempt to acquire dirty_lock again. The following lockdep report was observed on an RK3566 system with CONFIG_PROVE_LOCKING enabled: WARNING: possible irq lock inversion dependency detected swapper/2/0 just changed the state of lock: (console_owner){-...}-{0:0} but this lock took another, HARDIRQ-unsafe lock in the past: (&par->dirty_lock){+.+.}-{2:2} CPU0 CPU1 ---- ---- lock(&par->dirty_lock); local_irq_disable(); lock(console_owner); lock(&par->dirty_lock); lock(console_owner); *** DEADLOCK *** Use spin_lock_irqsave() for fbtft_mkdirty() and spin_lock_irq() for fbtft_deferred_io(). They only access the dirty line range, so the IRQ-off regions remain short. Fixes: c296d5f9957c ("staging: fbtft: core support") Signed-off-by: Hui Su --- Changes in v2: - Drop the comment explaining the lock ordering in fbtft_mkdirty(). - Use spin_lock_irq() in fbtft_deferred_io(), since it runs in workqueue context with interrupts enabled. v1: https://lore.kernel.org/lkml/20260804173712.176017-1-sh_def@163.com/ drivers/staging/fbtft/fbtft-core.c | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/drivers/staging/fbtft/fbtft-core.c b/drivers/staging/fbtft/fbtft-core.c index ca0c38221c16..7925d974de80 100644 --- a/drivers/staging/fbtft/fbtft-core.c +++ b/drivers/staging/fbtft/fbtft-core.c @@ -298,14 +298,15 @@ static void fbtft_mkdirty(struct fb_info *info, int y, int height) { struct fbtft_par *par = info->par; struct fb_deferred_io *fbdefio = info->fbdefio; + unsigned long flags; /* Mark display lines/area as dirty */ - spin_lock(&par->dirty_lock); + spin_lock_irqsave(&par->dirty_lock, flags); if (y < par->dirty_lines_start) par->dirty_lines_start = y; if (y + height - 1 > par->dirty_lines_end) par->dirty_lines_end = y + height - 1; - spin_unlock(&par->dirty_lock); + spin_unlock_irqrestore(&par->dirty_lock, flags); /* Schedule deferred_io to update display (no-op if already on queue)*/ schedule_delayed_work(&info->deferred_work, fbdefio->delay); @@ -318,13 +319,13 @@ static void fbtft_deferred_io(struct fb_info *info, struct list_head *pagereflis struct fb_deferred_io_pageref *pageref; unsigned int y_low = 0, y_high = 0; - spin_lock(&par->dirty_lock); + spin_lock_irq(&par->dirty_lock); dirty_lines_start = par->dirty_lines_start; dirty_lines_end = par->dirty_lines_end; /* set display line markers as clean */ par->dirty_lines_start = par->info->var.yres - 1; par->dirty_lines_end = 0; - spin_unlock(&par->dirty_lock); + spin_unlock_irq(&par->dirty_lock); /* Mark display lines as dirty */ list_for_each_entry(pageref, pagereflist, list) { -- 2.43.0