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: <ry4kzh4vr573ymutpjz5sgzmhosn3ekm3jatjy4yfyfm32eqit@cmp376je7viy>
Date: Tue, 13 Aug 2024 23:53:17 +0100
From: Andi Shyti <andi.shyti@...nel.org>
To: Breno Leitao <leitao@...ian.org>
Cc: Laxman Dewangan <ldewangan@...dia.com>, 
	Dmitry Osipenko <digetx@...il.com>, Thierry Reding <thierry.reding@...il.com>, 
	Jonathan Hunter <jonathanh@...dia.com>, leit@...a.com, Michael van der Westhuizen <rmikey@...a.com>, 
	Andy Shevchenko <andy@...nel.org>, 
	"open list:I2C SUBSYSTEM HOST DRIVERS" <linux-i2c@...r.kernel.org>, 
	"open list:TEGRA ARCHITECTURE SUPPORT" <linux-tegra@...r.kernel.org>, open list <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v2] Do not mark ACPI devices as irq safe

Hi Breno,

You don't need to resend the patch. Because the changes are only
in the commit log, I can take care of them.

First of all, we need to fix the title to be:

"i2c: tegra: Do not mark ACPI devices as irq safe"

On Tue, Aug 13, 2024 at 09:12:53AM GMT, Breno Leitao wrote:
> 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

We can keep the trace as:

	BUG: sleeping function called from invalid context at kernel/locking/mutex.c:585
	...

	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>

I haven't seen Andy explicitly tagging this patch. Andy, can we
keep it? Or have I missed it.

Besides, you also need:

Fixes: ede2299f7101 ("i2c: tegra: Support atomic transfers")
Cc: <stable@...r.kernel.org> # v5.6+

Can you please check whether this is right?

This patch won't apply, though, as far as 5.6 so you should
expect to provide some support for the stable backport.

Andi

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ