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/
