linux-kernel - [Update][PATCH] PM / Hibernate: Fix s2disk regression related to unlock_system

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]

Date:	Wed, 18 Jan 2012 00:15:56 +0100
From:	"Rafael J. Wysocki" <rjw@...k.pl>
To:	Linux PM list <linux-pm@...r.kernel.org>
Cc:	"Srivatsa S. Bhat" <srivatsa.bhat@...ux.vnet.ibm.com>,
	LKML <linux-kernel@...r.kernel.org>
Subject: [Update][PATCH] PM / Hibernate: Fix s2disk regression related to unlock_system_sleep()

From: Rafael J. Wysocki <rjw@...k.pl>
Subject: PM / Hibernate: Fix s2disk regression related to unlock_system_sleep()

Commit bcda53faf5814c0c6025a0bd47108adfcbe9f199, "PM / Sleep: Replace
mutex_[un]lock(&pm_mutex) with [un]lock_system_sleep()", modified
snapshot_read() and snapshot_write() in kernel/power/user.c, among
other things, by making them use lock_system_sleep() and
unlock_system_sleep() instead of just locking and unlocking pm_mutex.
Unfortunately, however, this was a mistake, because these routines
are supposed to be executed after processes have been frozen
(i.e. when system_freezing_cnt is nonzero), so when
unlock_system_sleep() is executed by one of them, this causes the
caller to execute try_to_freeze() and go into the refrigerator as
a result.  This, in turn, deadlocks the suspend process and locks up
the system.

Fix the problem by reverting the part of commit bcda53faf5814c0c6025a
that changed snapshot_read() and snapshot_write().

Signed-off-by: Rafael J. Wysocki <rjw@...k.pl>
---

Well, it wasn't a good idea to make snapshot_write() check
system_freezing_cnt, because the resume process doesn't freeze tasks.
So, it's better to simply revert the changes that introduced the
original regression.

Thanks,
Rafael

---
 kernel/power/user.c |    8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

Index: linux/kernel/power/user.c
===================================================================
--- linux.orig/kernel/power/user.c
+++ linux/kernel/power/user.c
@@ -137,7 +137,7 @@ static ssize_t snapshot_read(struct file
 	ssize_t res;
 	loff_t pg_offp = *offp & ~PAGE_MASK;

-	lock_system_sleep();
+	mutex_lock(&pm_mutex);

 	data = filp->private_data;
 	if (!data->ready) {
@@ -158,7 +158,7 @@ static ssize_t snapshot_read(struct file
 		*offp += res;

  Unlock:
-	unlock_system_sleep();
+	mutex_unlock(&pm_mutex);

 	return res;
 }
@@ -170,7 +170,7 @@ static ssize_t snapshot_write(struct fil
 	ssize_t res;
 	loff_t pg_offp = *offp & ~PAGE_MASK;

-	lock_system_sleep();
+	mutex_lock(&pm_mutex);

 	data = filp->private_data;

@@ -187,7 +187,7 @@ static ssize_t snapshot_write(struct fil
 	if (res > 0)
 		*offp += res;
 unlock:
-	unlock_system_sleep();
+	mutex_unlock(&pm_mutex);

 	return res;
 }
--
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/