I am looking at version 3.4 在 2013-2-16，0:17，Valdis.Kletnieks@xxxxxx 写道： > 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@xxxxxxx> 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@xxxxxxxxxxxxxxxxx > http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies _______________________________________________ Kernelnewbies mailing list Kernelnewbies@xxxxxxxxxxxxxxxxx http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
