Re: Re: printk in interrupt handlers?

[Mulyadi Santosa <mulyadi.santosa@xxxxxxxxx>]

Hi...

> Thanks a lot for all the replies. The pointer to __switch_to revealed
> the problem.
>
> The lock-up happens indepently of whether the message is printed on
> the console or just logged to the buffer. Also, the printk was not
> placed in __switch_to() but rather in schedule() itself. The problem
> is that printk may call try_to_wake_up() which in turn will try to
> acquire a runqueue lock ( of the CPU where klogd ran the last time).
> That could be the excact same lock that schedule() already holds.
> This, of course, deadlocks the CPU as recursive locking of spin locks
> is not supported in the kernel.

Thanks for sharing your finding, I really appreciate it. In fact, this 
is a quite new information for me too since once I also thought it was 
safe to call printk() in *any* context.

Maybe this is an additional question, what function are we supposed to 
use to log message inside this kind of context? Let me guess, relayfs? 
Or... should we build netlink connection and use it to pipe the 
information to user space logger? Any inputs are greatly appreciated.

regards,

Mulyadi


--
Kernelnewbies: Help each other learn about the Linux kernel.
Archive:       http://mail.nl.linux.org/kernelnewbies/
FAQ:           http://kernelnewbies.org/faq/