> From: mulyadi.sant...@gmail.com
> Date: Sun, 17 Feb 2013 12:37:21 +0700
> Subject: Re: spinlock deadlock
> To: bu...@live.cn
> CC: kernelnewbies@kernelnewbies.org
>
> On Fri, Feb 15, 2013 at 3:52 PM, buyitian <bu...@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
_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
