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