What happens when kernel code is interrupted?

Question

I am reading Operating System Concepts (Silberschatz,Galvin,Gagne), 6th edition, chapter 20. I understand that Linux kernel code is non preemptible (before 2.6 version). But it can be interrupted by hardware interrupts. What happens if the kernel was in the middle of a critical section and the interrupt occured and it too executed the critical section?

From what I read in the book:

The second protection scheme that Linux uses applies to critical sections that occur in the interrupt service routines. The basic tool is the processor interrupt control hardware...

Ok, this scheme is used when an ISR has a critical section. But it will only disble further interrupts. What about the kernel code which was interrupted by this interrupt in the first place?

Answer 1

But it will only disble further interrupts. What about the kernel code which was interrupted by this interrupt in the first place?

If the interrupt handler and other kernel code need access to the same data, you need to protect against that, which is usually done by a spinlock , great care must be taken, you don't want to introduce a deadlock ,and you must ensure such a spinlock is not held for too long. For spinlocks used in a hardware interrupt handler you have to disable interrupts on that processor whilst holding the lock - which in linux is done with the function spin_lock_irqsave().

(whilst a bit outdated, you can read about the concept here)

Answer 2

The kernel code which was interrupted by this interrupt in the first place gets interrupted.

This is why writing interrupt handlers is such a painful task: they can't do anything that would endanger the correctness of the main stream of execution.

For example, the way Apple's xnu kernel handles most kinds of device interrupts is to capture the information in the interrupt to a record in memory, add that record to a queue, and then resume normal execution; the kernel then picks up interrupts from the queue some time later (in the scheduler's main loop, i assume). That way, the interrupt handler only interacts with the rest of the system through the interrupt queue, and there is little danger of it causing trouble.

There is a bit of middle ground; on many architectures (including the x86), it is possible for privileged code to mask interrupts, so that they won't cause interruption. That can be used to protect passages of code which really shouldn't be interrupted. However, those architectures typically also have non-maskable interrupts, which ignore the masking, so interruption still has to be considered.