16

everybody knows that interrupt handler should be short as possible. and adding functions like printk for debugging inside an interrupt handler is something that shouldn't be done. Actually, I tried it before when I was debugging the linux kernel for an interrupt driven char device I written, and it wrecked the timing of the driver.

The question I have, is why this is happening ? printk function is buffered ! it means, as far as I understand that the data is inserted in to a queue, and it's being handled later, most probably after the interrupt handler is finished.

So why doesn't it work ?

user457015
  • 960
  • 4
  • 14
  • 33
stdcall
  • 27,613
  • 18
  • 81
  • 125
  • 6
    Consider the possibility that your print-call just fills up the buffer, forcing it to flush. What will happen when doing I/O in your interrupt handler? – Some programmer dude Jan 05 '12 at 07:26
  • YES, it's really that bad. Thank you, and good night. – Jason Coco Jan 05 '12 at 07:34
  • 2
    It *does* work. `printk` is designed to be called from interrupt or process context. If it wasn't, it wouldn't be much use for debugging. You obviously don't call it in interrupt context in a production driver, though. – EML Mar 28 '16 at 14:40

2 Answers2

33

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.

Roland
  • 6,227
  • 23
  • 29
  • How is debugfs as an alternative to the trace_printk? Is it good enough or does it have any caveats too? – user31986 Dec 12 '13 at 02:40
  • That's not fully true for the kernels v3.x+ (or even starting with earlier ones) I think. OTOH the advice for `trace_printk()` I fully support. – 0andriy Apr 17 '23 at 06:51
-10

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.)

zvrba
  • 24,186
  • 3
  • 55
  • 65
  • 11
    The question is about `printk`, not `printf` which doesn't even exist in the kernel. And the Linux kernel's `printk` is reentrant and can be called from interrupt context etc. So this answer is totally misguided. – Roland Jan 05 '12 at 20:54
  • Uh, I misread the title, and the function name has a funky trailing character in his post :/ – zvrba Jan 05 '12 at 21:15
  • 1
    Seriously what are you trying to add in to the discussion? I wonder why that reply is not marked negative! – user31986 Dec 12 '13 at 02:44