Re: [REGRESSION] [3.9-rc1] BUG: ktpacpi_nvramd/446 still has locks held!

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, Mar 4, 2013 at 11:28 PM, Aaron Lu <aaron.lu@xxxxxxxxx> wrote:
> On 03/05/2013 03:55 AM, Maciej Rutecki wrote:
>> Last known good: 3.8.0
>> Bad version: 3.9-rc1
>>
>> [    6.116492] =====================================
>> [    6.116614] [ BUG: ktpacpi_nvramd/446 still has locks held! ]
>> [    6.116737] 3.9.0-rc1 #1 Not tainted
>> [    6.116821] -------------------------------------
>> [    6.116900] 1 lock held by ktpacpi_nvramd/446:
>> [    6.116973]  #0:  (&hotkey_thread_mutex){+.+...}, at: [<ffffffffa024e87e>]
>> hotkey_kthread+0x1f/0x354 [thinkpad_acpi]
>> [    6.117193]
>> [    6.117193] stack backtrace:
>> [    6.117268] Pid: 446, comm: ktpacpi_nvramd Not tainted 3.9.0-rc1 #1
>> [    6.117381] Call Trace:
>> [    6.117445]  [<ffffffff810877ea>] debug_check_no_locks_held+0x8f/0x93
>> [    6.117600]  [<ffffffff8107d8ac>] set_freezable+0x3e/0x64
>> [    6.117703] input: ThinkPad Extra Buttons as
>> /devices/platform/thinkpad_acpi/input/input5
>> [    6.117918]  [<ffffffffa024e890>] hotkey_kthread+0x31/0x354 [thinkpad_acpi]
>> [    6.118088]  [<ffffffffa024e85f>] ? issue_volchange.29885+0x54/0x54
>> [thinkpad_acpi]
>> [    6.118250]  [<ffffffff8105e296>] kthread+0xac/0xb4
>> [    6.118356]  [<ffffffff8105e1ea>] ? __kthread_parkme+0x60/0x60
>> [    6.118491]  [<ffffffff814b243c>] ret_from_fork+0x7c/0xb0
>> [    6.118614]  [<ffffffff8105e1ea>] ? __kthread_parkme+0x60/0x60
>>
>> Config:
>> http://mrutecki.pl/download/kernel/3.9.0-rc1/config-3.9.0-rc1
>>
>> full dmesg:
>> http://mrutecki.pl/download/kernel/3.9.0-rc1/dmesg-3.9.0-rc1.txt
>>
>
> Thanks for the report!
>
> Looks like the following commit is related:
> commit 6aa9707099c4b25700940eb3d016f16c4434360d
> Author: Mandeep Singh Baines <msb@xxxxxxxxxxxx>  Thu Feb 28 09:03:18 2013
>
> lockdep: check that no locks held at freeze time
>
> And the code to trigger this problem is here:
> static int hotkey_kthread(void *data)
> {
>         struct tp_nvram_state s[2];
>         u32 poll_mask, event_mask;
>         unsigned int si, so;
>         unsigned long t;
>         unsigned int change_detector;
>         unsigned int poll_freq;
>         bool was_frozen;
>
>         mutex_lock(&hotkey_thread_mutex);
>
>         if (tpacpi_lifecycle == TPACPI_LIFE_EXITING)
>                 goto exit;
>
>         set_freezable();
> ~~~~~~~~~~~~~~~~~~~~~~~~~~
> in thinkpad_acpi.c.
>
> I don't know much about freeze, I've no idea what is the problem.
> So Mandeep and Henrique, can you please kindly take a look? Thanks.
>

Hi Aaron,

I will take a look at this.

In general, you don't want to grab a lock and freeze. You will block
suspend because another thread may try go grab the lock. In the case
of cgroup freezer, you could cause a deadlock.

There is also discussion happening on this thread:

https://lkml.org/lkml/2013/3/4/221

Regards,
Mandeep

> -Aaron
>

------------------------------------------------------------------------------
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


[Index of Archives]     [Linux ACPI]     [Linux Kernel]     [Linux Laptop]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Photo]     [Yosemite Photos]     [Yosemite Advice]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Device Mapper]

  Powered by Linux