linux-kernel - [PATCH v2] Do not mark ACPI devices as irq safe

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-next>] [day] [month] [year] [list]

Message-ID: <20240813161254.3509409-1-leitao@debian.org>
Date: Tue, 13 Aug 2024 09:12:53 -0700
From: Breno Leitao <leitao@...ian.org>
To: Laxman Dewangan <ldewangan@...dia.com>,
	Dmitry Osipenko <digetx@...il.com>,
	Andi Shyti <andi.shyti@...nel.org>,
	Thierry Reding <thierry.reding@...il.com>,
	Jonathan Hunter <jonathanh@...dia.com>
Cc: leit@...a.com,
	Michael van der Westhuizen <rmikey@...a.com>,
	Andy Shevchenko <andy@...nel.org>,
	linux-i2c@...r.kernel.org (open list:I2C SUBSYSTEM HOST DRIVERS),
	linux-tegra@...r.kernel.org (open list:TEGRA ARCHITECTURE SUPPORT),
	linux-kernel@...r.kernel.org (open list)
Subject: [PATCH v2] Do not mark ACPI devices as irq safe

On ACPI machines, the tegra i2c module encounters an issue due to a
mutex being called inside a spinlock. This leads to the following bug:

	BUG: sleeping function called from invalid context at kernel/locking/mutex.c:585
	in_atomic(): 0, irqs_disabled(): 1, non_block: 0, pid: 1282, name: kssif0010
	preempt_count: 0, expected: 0
	RCU nest depth: 0, expected: 0
	irq event stamp: 0

	Call trace:
	__might_sleep
	__mutex_lock_common
	mutex_lock_nested
	acpi_subsys_runtime_resume
	rpm_resume
	tegra_i2c_xfer

The problem arises because during __pm_runtime_resume(), the spinlock
&dev->power.lock is acquired before rpm_resume() is called. Later,
rpm_resume() invokes acpi_subsys_runtime_resume(), which relies on
mutexes, triggering the error.

To address this issue, devices on ACPI are now marked as not IRQ-safe,
considering the dependency of acpi_subsys_runtime_resume() on mutexes.

Co-developed-by: Michael van der Westhuizen <rmikey@...a.com>
Signed-off-by: Michael van der Westhuizen <rmikey@...a.com>
Signed-off-by: Breno Leitao <leitao@...ian.org>
Reviewed-by: Dmitry Osipenko <digetx@...il.com>
Reviewed-by: Andy Shevchenko <andy@...nel.org>
---
Changelog:
v2:
  * Replaced ACPI_HANDLE() by has_acpi_companion() (Andy Shevchenko)
  * Expanded the comment before the change (Andy Shevchenko)
  * Simplified the stack in the summary (Andy Shevchenko)

 drivers/i2c/busses/i2c-tegra.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/i2c/busses/i2c-tegra.c b/drivers/i2c/busses/i2c-tegra.c
index 85b31edc558d..1df5b4204142 100644
--- a/drivers/i2c/busses/i2c-tegra.c
+++ b/drivers/i2c/busses/i2c-tegra.c
@@ -1802,9 +1802,9 @@ static int tegra_i2c_probe(struct platform_device *pdev)
 	 * domain.
 	 *
 	 * VI I2C device shouldn't be marked as IRQ-safe because VI I2C won't
-	 * be used for atomic transfers.
+	 * be used for atomic transfers. ACPI device is not IRQ safe also.
 	 */
-	if (!IS_VI(i2c_dev))
+	if (!IS_VI(i2c_dev) && !has_acpi_companion(i2c_dev->dev))
 		pm_runtime_irq_safe(i2c_dev->dev);
 
 	pm_runtime_enable(i2c_dev->dev);
-- 
2.43.5