When Driver Code Is Allowed to Sleep
Kernel code runs in two very different situations: normal context, where the scheduler may park your thread and run something else, and atomic context, such as inside an interrupt handler or while holding a spinlock, where parking is forbidden because nothing can run to wake you up. Anything that might wait, including most memory allocation and any mutex, is illegal in the second situation, and doing it anyway can freeze the whole machine. Nearly every choice in the rest of driver writing, which lock to take, which allocation flag to pass, whether to defer work, is really a question of which context you are in.
Questions this Concept answers
- Why can sleeping in atomic context freeze the whole machine rather than just delaying your driver?
This Concept is waiting for its first lesson!
Kernel code runs in two very different situations: normal context, where the scheduler may park your thread and run something else, and atomic context, such as inside an interrupt handler or while holding a spinlock, where parking is forbidden because nothing can run to wake you up. Anything that might wait, including most memory allocation and any mutex, is illegal in the second situation, and doing it anyway can freeze the whole machine. Nearly every choice in the rest of driver writing, which lock to take, which allocation flag to pass, whether to defer work, is really a question of which context you are in.
Are you a teacher? Sign in to start contributing.
Sign In