> 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 [off-list ref] wrote:

quoted

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