Printk or I/O dangers in interrupt handler

Question

Why is printk or (I/O) prohibited in interrupt handler in linux .? Under what condition I/O in a interrupt handler can cause deadlock in a linux system?

Answer 1

Regarding printk(), it is intrusive. For instance, problem you're debugging may disappear by adding printk's. Depending on settings, it may output to console which can be slow. trace_printk() of ftrace is recommended instead.

As for I/O inside an interrupt, remember that interrupts run at higher priority than other threads of execution, so any latency - whether I/O or something else - will have a knock on effect on rest of the system.

Deadlocks can happen due to resource contention. For example, an interrupt arrives at a time when one resource, say a mutex, is already taken by a kernel thread running in process context. Now an attempt by interrupt service routine wants to acquire the same resource will result in deadlock: kernel thread can't run because ISR has higher priority and ISR can't finish because it's waiting on the resource held by kernel thread.

Hope it answers your query.

UPDATE: Will calling printk in interrupt handler cause a deadlock? No. For example this extract from makelinux

One property of printk() quickly taken for granted is its robustness. The printk() function is callable from just about anywhere in the kernel at any time. It can be called from interrupt or process context. It can be called while a lock is held. It can be called simultaneously on multiple processors, yet it does not require the caller to hold a lock.

UPDATE2: Word of caution thanks to tc2keats.

However, if printk is in ISR, it's unlikely to be production code. Probably debugging. So if there is a lock up it should become apparent to the programmer :)