[PATCH] thinkpad_acpi: moved hotkey_thread_mutex lock after set_freezable()

[PATCH] thinkpad_acpi: moved hotkey_thread_mutex lock after set_freezable()

[Artem Savkov]

set_freezable() checks freezing during which no locks should be held.
hotkey_thread_mutex lock should be moved closer to where it is actually needed.

Signed-off-by: Artem Savkov <artem.savkov@gmail.com>
---
 drivers/platform/x86/thinkpad_acpi.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/platform/x86/thinkpad_acpi.c b/drivers/platform/x86/thinkpad_acpi.c
index 22d8936..ffed96cd 100644
--- a/drivers/platform/x86/thinkpad_acpi.c
+++ b/drivers/platform/x86/thinkpad_acpi.c
@@ -2463,13 +2463,13 @@ static int hotkey_kthread(void *data)
 	unsigned int poll_freq;
 	bool was_frozen;
 
-	mutex_lock(&hotkey_thread_mutex);
-
 	if (tpacpi_lifecycle == TPACPI_LIFE_EXITING)
 		goto exit;
 
 	set_freezable();
 
+	mutex_lock(&hotkey_thread_mutex);
+
 	so = 0;
 	si = 1;
 	t = 0;
@@ -2523,8 +2523,8 @@ static int hotkey_kthread(void *data)
 		si ^= 1;
 	}
 
-exit:
 	mutex_unlock(&hotkey_thread_mutex);
+exit:
 	return 0;
 }
 
-- 
1.8.1.4

Re: [PATCH] thinkpad_acpi: moved hotkey_thread_mutex lock after set_freezable()

[Andrew Morton]

On Sun, 24 Feb 2013 13:22:02 +0400
Artem Savkov <artem.savkov@gmail.com> wrote:

> set_freezable() checks freezing during which no locks should be held.
> hotkey_thread_mutex lock should be moved closer to where it is actually needed.
> 

Thanks.

When fixing a bug, we always like to see a full description of that bug
so we can better work out which kernel versions need the fix.

Did you actually hit a lockup because of this?  Or was it just from
code inspection?  Or ...  ?

Re: [PATCH] thinkpad_acpi: moved hotkey_thread_mutex lock after set_freezable()

[Artem Savkov]

On Mon, Feb 25, 2013 at 03:54:45PM -0800, Andrew Morton wrote:
> On Sun, 24 Feb 2013 13:22:02 +0400
> Artem Savkov <artem.savkov@gmail.com> wrote:
> 
> > set_freezable() checks freezing during which no locks should be held.
> > hotkey_thread_mutex lock should be moved closer to where it is actually needed.
> > 
> 
> Thanks.
> 
> When fixing a bug, we always like to see a full description of that bug
> so we can better work out which kernel versions need the fix.
Sorry, will do thah in future.

> Did you actually hit a lockup because of this?  Or was it just from
> code inspection?  Or ...  ?
I didn't hit an actual lockup, but I did hit a warning during boot. The
warning was added by "lockdep: check that no locks held at freeze time"
patch (2f2ff7b8979c50491b3cbce622d7bea4d44a8682 in linux-next.git)


-- 
Kind regards,
Artem