Restrictions while kernel is running an ISR routine

5
votes

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 ?

1
operating-systemlockinglinux-kernelinterruptcontext-switch

1 Answers

4
votes

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