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.
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@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
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...
I am looking at version 3.4 在 2013-2-16，0:17，Valdis.Kletnieks@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@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
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@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@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
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
> From: mulyadi.santosa@gmail.com
> Date: Sun, 17 Feb 2013 12:37:21 +0700
> Subject: Re: spinlock deadlock
> To: buyit@live.cn
> CC: kernelnewbies@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
participants (5)
-
anish kumar -
anish singh
-
buyitian -
Mulyadi Santosa -
Valdis.Kletnieks＠vt.edu