Is there any guidelines on when and where can we insert printk() to do debugging? >From definition of printk() it calls vprintk(): kernel/printk.c: asmlinkage int vprintk(const char *fmt, va_list args) { static int log_level_unknown = 1; static char printk_buf[1024]; unsigned long flags; int printed_len = 0; int this_cpu; char *p; boot_delay_msec(); preempt_disable(); /* This stops the holder of console_sem just where we want him */ raw_local_irq_save(flags); So we can see that printk() MUST NOT BE USED when the kernel is preempt-disabled, as at the end of printk() it will be enabled again. MISUSE scenario: using printk() INSIDE a spin_lock()-spin_unlock() pair. Similarly, in spin_lock(), preemption is disabled, and therefore, it must be in enabled state before spin_lock() is used, and after spin_unlock() is called. MISUSE scenario (assuming everything here is happening on one CPU): In cases where cascaded spin_lock, calling the 2nd spin_unlock() will not have any effect on preemption, as it is already enabled by the first spin_unlock(), and therefore enabling it again by the 2nd spin_unlock() will not have any effect. But before calling the 2nd spin_lock(), the assumption that it is in preemption disabled mode is wrong. If interrupt should disrupt its execution path, then it will not reach the 2nd spin_unlock() immediately, if it encounter another spin_lock() on the same global variable, then it will deadlock - there is no way the spin_lock() will terminate, under the new preemption disabled mode: spin_unlock(A); ====> interrupt enabled here....right? So it goes out and apply spin_lock(B) again =====> deadlock? spin_unlock(B); COMMENTS? -- Regards, Peter Teoh -- To unsubscribe from this list: send an email with "unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx Please read the FAQ at http://kernelnewbies.org/FAQ