linux-kernel - [PATCH 0/2] ARM: omap2+: omap_hwmod: Fix false lockdep warning

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: <1423226916-18804-1-git-send-email-peter.ujfalusi@ti.com>
Date:	Fri, 6 Feb 2015 14:48:34 +0200
From:	Peter Ujfalusi <peter.ujfalusi@...com>
To:	Tony Lindgren <tony@...mide.com>, <paul@...an.com>
CC:	<linux-omap@...r.kernel.org>, <peterz@...radead.org>,
	<mingo@...hat.com>, <linux-kernel@...r.kernel.org>, <balbi@...com>,
	<linux-arm-kernel@...ts.infradead.org>
Subject: [PATCH 0/2] ARM: omap2+: omap_hwmod: Fix false lockdep warning

Hi,

In case when hwmods are used in nested way the lockdep validator will print out
a warning message about possible deadlock situation:

[    4.514882] =============================================
[    4.520530] [ INFO: possible recursive locking detected ]
[    4.526176] 3.14.30-00289-ge44872fdca8f-dirty #198 Not tainted
[    4.532285] ---------------------------------------------
[    4.537936] kworker/u4:1/18 is trying to acquire lock:
[    4.543317]  (&(&oh->_lock)->rlock){......}, at: [<c002d2dc>] omap_hwmod_enable+0x2c/0x58
[    4.552109] 
[    4.552109] but task is already holding lock:
[    4.558216]  (&(&oh->_lock)->rlock){......}, at: [<c002d2dc>] omap_hwmod_enable+0x2c/0x58
[    4.566999] 
[    4.566999] other info that might help us debug this:
[    4.573831]  Possible unsafe locking scenario:
[    4.573831] 
[    4.580025]        CPU0
[    4.582584]        ----
[    4.585142]   lock(&(&oh->_lock)->rlock);
[    4.589544]   lock(&(&oh->_lock)->rlock);
[    4.593945] 
[    4.593945]  *** DEADLOCK ***
[    4.593945] 
[    4.600146]  May be due to missing lock nesting notation

What lockdep did not realizes is that the two oh is not the same hwmod object
and we have taken different locks.

One example of nested hwmod usage is on DRA7xx platforms, where McASP can be
configured to use ATL clock as it's functional clock. In this case the
pm_runtime_get/put_sync call will enable the mcasp hwmod and as part of this
operation it will enable the needed clocks. Since ATL clock is needed, we will
have another pm_runtime operation from the ATL clock enable callback which
will take the atl hwmod's lock. This will be seen by lockdep as possible
deadlock situation.

In order to notify lockdep about this, we need to switch using _nested
version of locking function and assign different subclass to those hwmods which
could be used in nested way.

Regards,
Peter
---
Peter Ujfalusi (2):
  ARM: omap2+: omap_hwmod: Use _nested version of spinlock for oh->_lock
  ARM: DRA7: hwmod_data: Change locked_class for atl hwmod

 arch/arm/mach-omap2/omap_hwmod.c          | 16 ++++++++--------
 arch/arm/mach-omap2/omap_hwmod.h          |  5 +++++
 arch/arm/mach-omap2/omap_hwmod_7xx_data.c |  1 +
 3 files changed, 14 insertions(+), 8 deletions(-)

-- 
2.2.2

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/