spinlock deadlock

spinlock deadlock

[buyitian]

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. 

 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20130215/f5658f4a/attachment.html 

spinlock deadlock

[anish singh]

adding Joe Perches  as generally he looks after printk stuff.

On Fri, Feb 15, 2013 at 2:22 PM, buyitian <buyit@live.cn> 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.
>
>
>
> _______________________________________________
> Kernelnewbies mailing list
> Kernelnewbies at kernelnewbies.org
> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>

spinlock deadlock

[Valdis.Kletnieks at vt.edu]

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@live.cn> 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...
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 865 bytes
Desc: not available
Url : http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20130215/de7b1846/attachment.bin 

spinlock deadlock

[buyitian]

I am looking at version 3.4

? 2013-2-16?0:17?Valdis.Kletnieks at vt.edu ???

> 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@live.cn> 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 at kernelnewbies.org
> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

spinlock deadlock

[anish kumar]

On Sat, 2013-02-16 at 00:34 +0800, buyitian wrote:
> I am looking at version 3.4
> 
> ? 2013-2-16?0:17?Valdis.Kletnieks at vt.edu ???
> 
> > 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@live.cn> 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..
Can you ask this question in kernel maling list?I think you might get a
better reply to your queries.

> > _______________________________________________
> > Kernelnewbies mailing list
> > Kernelnewbies at kernelnewbies.org
> > http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

spinlock deadlock

[Mulyadi Santosa]

On Fri, Feb 15, 2013 at 3:52 PM, buyitian <buyit@live.cn> 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.

I began to get rusty on this...but, why do you grab run queue lock?


-- 
regards,

Mulyadi Santosa
Freelance Linux trainer and consultant

blog: the-hydra.blogspot.com
training: mulyaditraining.blogspot.com

spinlock deadlock

[buyitian]

 > From: mulyadi.santosa at gmail.com
> Date: Sun, 17 Feb 2013 12:37:21 +0700
> Subject: Re: spinlock deadlock
> To: buyit at live.cn
> CC: kernelnewbies at kernelnewbies.org
> 
> On Fri, Feb 15, 2013 at 3:52 PM, buyitian <buyit@live.cn> 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.
> 
> I began to get rusty on this...but, why do you grab run queue lock?
> 
>     i want to know why the authors use spinlock and semaphore like this, because the change history is very insteresting:1. in patch 0b5e1c5255e7ee8670e077e8224e5c2281229a5b: Peter did below changes:    (1). in function console_trylock_for_printk():if (!can_use_console(cpu)) {
    console_locked = 0;
-   up(&console_sem);
+   wake = 1;
    retval = 0;
   }
  }
  printk_cpu = UINT_MAX;
  spin_unlock(&logbuf_lock);
+ if (wake)
+  up(&console_sem);           (2). in function console_unlock(): - up(&console_sem);
  spin_unlock_irqrestore(&logbuf_lock, flags);
+ up(&console_sem);
  if (wake_klogd)
   wake_up_klogd();
 }           this patch is to prevent deadlock between rq->lock and logbuf_lock. i can understand this thanks to Rabin. 2. in patch 07354eb1a74d1e1ece29f8bafe0b46e8c77a95ef, Thomas did changes as below, which reverted the change from peter, i don't know why:    in function console_trylock_for_printk(): - spin_unlock(&logbuf_lock);
  if (wake)
   up(&console_sem);
+ raw_spin_unlock(&logbuf_lock);        and this change exists in the latest kernel source code. it seems that deadlock bewteen rq->lock and logbuf_lock comes back, who can explain this, thanks.      BTW: if i place printk inside schedule(), i may get rq->lock before calling printk.
> -- 
> regards,
> 
> Mulyadi Santosa
> Freelance Linux trainer and consultant
> 
> blog: the-hydra.blogspot.com
> training: mulyaditraining.blogspot.com
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20130217/8c5fce42/attachment.html 

spinlock deadlock

[buyitian]

 > Date: Mon, 18 Feb 2013 10:54:44 +0100
> From: tglx at linutronix.de
> To: buyit at live.cn
> CC: mulyadi.santosa at gmail.com; kernelnewbies at kernelnewbies.org; a.p.zijlstra at chello.nl; rabin at rab.in; mingo at kernel.org
> Subject: RE: spinlock deadlock
> 
> On Sun, 17 Feb 2013, buyitian wrote:
> 
> Could you please use a mail client, which creates readable mail?
> 
> > this patch is to prevent deadlock between rq->lock and
> > logbuf_lock. i can understand this thanks to Rabin. 2. in patch
> > 07354eb1a74d1e1ece29f8bafe0b46e8c77a95ef, Thomas did changes as
> > below, which reverted the change from peter, i don't know why: in
> > function console_trylock_for_printk():
> 
> > - spin_unlock(&logbuf_lock);
> >   if (wake)
> >    up(&console_sem);
> > + raw_spin_unlock(&logbuf_lock);
> 
> > and this change exists in the latest kernel source code. it seems
> > that deadlock bewteen rq->lock and logbuf_lock comes back, who can
> > explain this, thanks.  BTW: if i place printk inside schedule(), i
> > may get rq->lock before calling printk.
> 
> That looks like a merge slipup. The patch which converts the lock is
> not supposed to do any other changes. But the patch was based on an
> older kernel version, which did not have Peters changes yet. So the
> fixup of the not longer applying patch failed somehow.  i will provide patch, thanks for your reply.
> 
> Thanks,
> 
> 	tglx
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20130218/36428bc9/attachment.html