0

Let's assume that we have an interrupt handler and a tasklet in Linux. The tasklet is scheduled from this interrupt handler.

The interrupt handler works as a some kind of producer, and tasklet as consumer. The problem occurs when the tasklet runs for longer time and interrupt occures when this tasklet is still running. This interferences causes several calltraces in logs.

How to resolve this kind of interferences?

The only idea I've got is to move the interrupt handler to some workqueue or another tasklet and schedule it from the interrupt handler.

Is it ok? Any other ideas?

Peter L.
  • 1,041
  • 2
  • 22
  • 26
user2699113
  • 4,262
  • 3
  • 25
  • 43
  • 3
    Rule of thumb for systems programming: do as little as possible in an ISR. – DoxyLover Sep 12 '14 at 17:21
  • 1
    Short answer: fix the bug(s) in your code (which you have not shown). – CL. Sep 13 '14 at 11:35
  • If your code causes calltraces then fix your code. If it's intervention between ISR and tasklet and you're sure tasklet is fine then use workqueue instead of tasklet. Workqueues runs in process context and can sleep in case of new interrupt. – Alexander Dzyoba Sep 15 '14 at 07:10
  • First - the most interesting thing in this problem is that the calltraces occures only in kernel sources, not in the driver. Second - I've prevented occuring of interferences by disabling IRQ on the beginning of tasklet and enabling them on the end of tasklet. The problematic calltrace occures in process_backlog() procedure while deleting list napi->poll_list, because this proc tries to delete already deleted poll_list. – user2699113 Sep 15 '14 at 08:29
  • Use spinlocks around your tasklet code, `spin_lock_irqsave()` to disable the interrupts. And rule of thumb ofcouse as said above is do little things in tasklets. – Milind Dumbare Feb 20 '15 at 09:19

1 Answers1

0

My suggestion is move the heavy process to the userspace, and add a frame drop

Long Yang
  • 1