On 2/8/07, Dong Feng <middle.fengdong@xxxxxxxxx> wrote:
2007/2/9, Mulyadi Santosa <mulyadi.santosa@xxxxxxxxx>: > Hi Dong Feng > > My understanding is that a *sleep* operation may cause block, but a > > *wake-up* operation never. And I heard that it is safe to invoke > > printk() in an interrupt handler. Of course not put printk() in > > __switch_to(), but that seems because of some other reason. > Maybe you're right. My other idea is, since printk deals with console > output, maybe if you are doing it inside an interrupt handler that > directly or indirectly deal with console, then it will trigger oops. > > Just another 2 cents speculation. Yes, printk() deals with console. But I guess it does not always but only when it is safe to do that. If the context does not allow console-interaction, the printk() simply put the logged message to a memory buffer and wait for a user space process move the message out later. Not confirm by code in details. :-) So welcome other's comments.
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. Curiously, the comment at printk does not mention any interaction with the runqueue locks. Thanks for the help, Bjoern -- Kernelnewbies: Help each other learn about the Linux kernel. Archive: http://mail.nl.linux.org/kernelnewbies/ FAQ: http://kernelnewbies.org/faq/
