Process context vs. Interrupt context
system calls run in process context – can sleep
interrupt handlers run in interrupt context – cannot sleep
Interrupt handler
all handlers share one interrupt stack per processor
spin_lock()
/ spin_unlock()
keep the critical section as small as possible
spin_lock_irqsave()
/ spin_unlock_irqrestore()
disable all interrupts on local CPU, lock, unlock, restore interrupts to how it was before
need to use this version if the lock is something that an interrupt handler may try to acquire
no need to worry about interrupts on other CPUs – spin lock will work normally
again, no need to spin in uniproc – just ++preempt_count & disable irq
spin_lock_irq()
/ spin_unlock_irq()
disable & enable irq assuming it was disabled to begin with
should not be used in most cases
If TIF_NEED_RESCHED
is set, preemption occurs by calling schedule()
in
the following cases:
Returning to user space:
from a system call
from an interrupt handler
Returning to kernel from an interrupt handler, only if
preempt_count
is zero
preempt_count
just became zero – right after spin_unlock(), for
example
Thread running in kernel mode calls schedule() itself – blocking syscall, for example
Last updated: 2016–03–31