Restrictions while kernel is running an ISR routine
context-switch, interrupt, linux-kernel, locking, operating-system
Solution
In short: NO CONTEXT SWITCH, EVER.
This means:
- No preemption
- No locks on mutexes (use spin locks instead and ensure your non-ISR counterparts acquire them with spin_lock_irqsave to disable IRQs)
- No call to any kernel function that can sleep (check the function's documentation, some functions also have _cansleep variants).
A process switch can occur on a page fault, but it happens after the corresponding ISR has been processed. Basically a path can be scheduled if it is not an ISR and if you do not have a spinlock locked. If you hold a spinlock, you must avoid sleeping until it is released.
Since ISRs are very restrained, then handling of IRQs is usually split between a top-half (that runs in ISR context and does the critical job) and a bottom-half (that runs later as a kernel thread and does whatever can be delayed) which can sleep. See this page for more information:
http://www.makelinux.net/ldd3/chp-10-sect-4
Problem
What are some of the important do's and dont's inside a kernel mode and ISR Routine ? For example - - Is context-switching disabled while running an interrupt handler ? - Can a context switch happen when a process is inside a critical section ? - What circumstances inside kernel mode merit disabling of further interrupts ? How come a process switch can occur on a page-fault, where a process fetches data from the disk, but not happen during other occurences of interrupts. How do you classify if a executable path can be interrupted/rescheduled/pre-empted ? What are the other things one has to remember when process is in kernel mode or handling ISR routine ?