On Tue, 5 Mar 2013 09:34:43 -0800 Mandeep Singh Baines <msb@xxxxxxxxxxxx> wrote: > Fixes the following lockdep error: > > [ BUG: ktpacpi_nvramd/446 still has locks held! ] > > hotkey_kthread() calls set_freezable() after acquiring the > hotkey_kthread_mutex(). set_freezable() calls try_to_freeze(). > This could block suspend if we were to freeze at this point > and another task were to block on the mutex, potentially via > writing to one of the sysfs attrs. This race is unlikely but > can be easily fixed by moving the set_freezable() call. > > ... > > --- a/drivers/platform/x86/thinkpad_acpi.c > +++ b/drivers/platform/x86/thinkpad_acpi.c > @@ -2462,13 +2462,13 @@ static int hotkey_kthread(void *data) > unsigned int poll_freq; > bool was_frozen; > > + set_freezable(); > + > mutex_lock(&hotkey_thread_mutex); > > if (tpacpi_lifecycle == TPACPI_LIFE_EXITING) > goto exit; > > - set_freezable(); > - > so = 0; > si = 1; > t = 0; Basically the same as http://ozlabs.org/~akpm/mmots/broken-out/drivers-platform-x86-thinkpad_acpic-move-hotkey_thread_mutex-lock-after-set_freezable.patch. I think Artem's patch is a little better. There doesn't appear to be any locking protocol for tpacpi_lifecycle. I'll move Artem's patch into my for-3.9-rc2 queue. ------------------------------------------------------------------------------ Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" in the endpoint security space. For insight on selecting the right partner to tackle endpoint security challenges, access the full report. http://p.sf.net/sfu/symantec-dev2dev _______________________________________________ ibm-acpi-devel mailing list ibm-acpi-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.sourceforge.net/lists/listinfo/ibm-acpi-devel
