Re: spinlock deadlock

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

 



I am looking at version 3.4

在 2013-2-16,0:17,Valdis.Kletnieks@xxxxxx 写道:

> On Fri, 15 Feb 2013 17:17:38 +0530, anish singh said:
>> adding Joe Perches  as generally he looks after printk stuff.
>> 
>> On Fri, Feb 15, 2013 at 2:22 PM, buyitian <buyit@xxxxxxx> wrote:
>>> is it possible that printk cause deadlock? the path is as below:
>>> 
>>> 1. taskA runs on CPU0, and run schedule to acqire the rq->lock.
>>> 2. taskA calls printk while holding rq->lock.
>>> 3. taskA holds console_sem.
>>> 4. taskB runs on CPU1, and call console_lock(), which is blocked by
>>> console_sem and queue itslef to the wait list.
>>> 5. taskB migrates from CPU1 to cpu0. will this step occur?
>>> 6. taskA calls up(&console_sem)-->
>>> wake_up_process()-->try_to_wake_up()-->ttwu_queue()-->raw_spin_lock(&rq->lock).
>>> here taskA tries to acquire the rq->lock of CPU0 again.
> 
> I'm not Joe, but what kernel release are you looking at?  ISTR that in
> the last few releases (3.5-ish maybe?), that code got overhauled to
> prevent a similar issue...
> _______________________________________________
> Kernelnewbies mailing list
> Kernelnewbies@xxxxxxxxxxxxxxxxx
> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@xxxxxxxxxxxxxxxxx
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies



[Index of Archives]     [Newbies FAQ]     [Linux Kernel Mentors]     [Linux Kernel Development]     [IETF Annouce]     [Git]     [Networking]     [Security]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux SCSI]     [Linux ACPI]
  Powered by Linux