Skip to contentSkip to conversation

Hibernation: Fix lockdep report (v2)

PATCH In review Rafael J. Wysocki 3 participants 5 messages Nov 14, 2007

Subsystems (2)
lore
Share & tools
lore
#0 lore raw

PATCH 1/1 Hibernation: Fix lockdep report (v2)

[Andrew, please consider this as 2.6.24 material, thanks.]
---
From: Johannes Berg <[email protected]>

Lockdep reports a circular locking dependency in the hibernate code because
 - during system boot hibernate code (from an initcall) locks pm_mutex and then a sysfs buffer mutex via name_to_dev_t
 - during regular operation hibernate code locks pm_mutex under a sysfs buffer mutex because it's called from sysfs methods.

The deadlock can never happen because during initcall invocation nothing can write to sysfs yet. This removes the lockdep report by marking the initcall locking as being in a different class.

---
 kernel/power/disk.c |   12 +++++++++++-
 1 file changed, 11 insertions(+), 1 deletion(-)
kernel/power/disk.c +11 -1
Index: linux-2.6/kernel/power/disk.c
===================================================================
@@ -456,7 +456,17 @@ static int software_resume(void)
 	int error;
 	unsigned int flags;
 
-	mutex_lock(&pm_mutex);
+	/*
+	 * name_to_dev_t() below takes a sysfs buffer mutex when sysfs
+	 * is configured into the kernel. Since the regular hibernate
+	 * trigger path is via sysfs which takes a buffer mutex before
+	 * calling hibernate functions (which take pm_mutex) this can
+	 * cause lockdep to complain about a possible ABBA deadlock
+	 * which cannot happen since we're in the boot code here and
+	 * sysfs can't be invoked yet. Therefore, we use a subclass
+	 * here to avoid lockdep complaining.
+	 */
+	mutex_lock_nested(&pm_mutex, SINGLE_DEPTH_NESTING);
 	if (!swsusp_resume_device) {
 		if (!strlen(resume_file)) {
 			mutex_unlock(&pm_mutex);
#1 lore raw
Quoted 11 lines · Rafael J. Wysocki

[Andrew, please consider this as 2.6.24 material, thanks.]
---
From: Johannes Berg <[email protected]>

Lockdep reports a circular locking dependency in the hibernate code because
 - during system boot hibernate code (from an initcall) locks pm_mutex and then a sysfs buffer mutex via name_to_dev_t
 - during regular operation hibernate code locks pm_mutex under a sysfs buffer mutex because it's called from sysfs methods.

Quoted 8 lines

The deadlock can never happen because during initcall invocation nothing can write to sysfs yet. This removes the lockdep report by marking the initcall locking as being in a different class.

Cc Alan Stern <[email protected]>
Cc Peter Zijlstra <[email protected]>
Cc Pavel Machek <[email protected]>

ACK...

Signature · 2 lines
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
#2 lore raw
Quoted 12 lines · Pavel Machek
Quoted 11 lines · Rafael J. Wysocki

[Andrew, please consider this as 2.6.24 material, thanks.]
---
From: Johannes Berg <[email protected]>

Lockdep reports a circular locking dependency in the hibernate code because
- during system boot hibernate code (from an initcall) locks pm_mutex and then a sysfs buffer mutex via name_to_dev_t
- during regular operation hibernate code locks pm_mutex under a sysfs buffer mutex because it's called from sysfs methods.

Quoted 7 lines
Quoted 7 lines

The deadlock can never happen because during initcall invocation nothing can write to sysfs yet. This removes the lockdep report by marking the initcall locking as being in a different class.

Cc Alan Stern <[email protected]>
Cc Peter Zijlstra <[email protected]>

I guess mine got lost too :-)

Quoted 4 lines
Quoted 1 line
Cc Pavel Machek <[email protected]>

ACK...

#3 lore raw
In reply to Pavel Machek
Quoted 12 lines · Pavel Machek
Quoted 11 lines · Rafael J. Wysocki

[Andrew, please consider this as 2.6.24 material, thanks.]
---
From: Johannes Berg <[email protected]>

Lockdep reports a circular locking dependency in the hibernate code because
- during system boot hibernate code (from an initcall) locks pm_mutex and then a sysfs buffer mutex via name_to_dev_t
- during regular operation hibernate code locks pm_mutex under a sysfs buffer mutex because it's called from sysfs methods.

Quoted 7 lines
Quoted 7 lines

The deadlock can never happen because during initcall invocation nothing can write to sysfs yet. This removes the lockdep report by marking the initcall locking as being in a different class.

Cc Alan Stern <[email protected]>
Cc Peter Zijlstra <[email protected]>

I guess mine got lost too :-)

Quoted 4 lines
Quoted 1 line
Cc Pavel Machek <[email protected]>

ACK...

#4 lore raw
In reply to Rafael J. Wysocki
Quoted 11 lines · Rafael J. Wysocki

[Andrew, please consider this as 2.6.24 material, thanks.]
---
From: Johannes Berg <[email protected]>

Lockdep reports a circular locking dependency in the hibernate code because
 - during system boot hibernate code (from an initcall) locks pm_mutex and then a sysfs buffer mutex via name_to_dev_t
 - during regular operation hibernate code locks pm_mutex under a sysfs buffer mutex because it's called from sysfs methods.

Quoted 8 lines

The deadlock can never happen because during initcall invocation nothing can write to sysfs yet. This removes the lockdep report by marking the initcall locking as being in a different class.

Cc Alan Stern <[email protected]>
Cc Peter Zijlstra <[email protected]>
Cc Pavel Machek <[email protected]>

ACK...

Signature · 2 lines
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html