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 [EMAIL PROTECTED]
Please read the FAQ at http://kernelnewbies.org/FAQ
