printk inside an interrupt handler , is it really that bad?

Question

everybody knows that interrupt handler should be short as possible. and adding functions like printk for debugging inside an interrupt handler is something that

Answer 1

Yes, it is very bad since printf most probably is not reentrant. What can happen is that the main program calls printf, an interrupt arrives while printf is executing, and then the IRQ handler calls printf again: very bad things may happen (e.g., deadlock, corrupt internal buffers, etc.)

Answer 2

The printk function is not just inserting into a queue/buffer -- assuming the log level is high enough, the output from printk will be emitted to the console immediately, as part of the call to printk. This is especially slow if the console is, say, on a serial port. But in any case, printk does introduce pretty substantial overhead and can affect timing.

If you have a timing critical place where you want to get some debug output, you can look at using the trace_printk function in modern kernels. This actually does just put input into the trace ringbuffer, and you can read it later. Take a look at this article for full details.