The contexts the kernel is in while in kernel space

Question

The following excerpt is from Linux Kernel Development(LKD) by Robert Love.

These contexts represent the breadth of the kernel’s activities. In fact, in Linux, we can generalize that each processor is doing exactly one of three things at any given moment:

1. In user-space, executing user code in a process
2. In kernel-space, in process context, executing on behalf of a specific process
3. In kernel-space, in interrupt context, not associated with a process, handling an interrupt

This list is inclusive. Even corner cases fit into one of these three activities: For exam- ple, when idle, it turns out that the kernel is executing an idle process in process context in the kernel.

What I grasped from above is that when in Kernel-space, there are only two contexts(it's inclusive, according to Love), i.e., process context & interrupt context. To my understanding, the kernel enters process context when a process invokes a system call(e.g., read(), write(), etc.), while interrupt context happens when the kernel handles an interrupt.

But there are far more other functionalities in the kernel, for instance, there are kernel threads scheduled to do routine works(e.g., reclaiming memory), and even the scheduler itself is neither invoked by a system call nor by an interrupt.

So I wonder why the text says there are only two contexts in the kernel...?

Answer 1

The most important parts of a context are address space(or virtual memory) and cpu state(like register value, program counter etc.). From this aspect of view, there should be other two kind of contexts: kernel context and kernel-thread context.

Kernel itself runs in kernel space don't depend on tasks(including normal process and kernel threads). Its context is called idle context or swapper context.

Kernel threads also don't rely on any normal process context. They are scheduled like normal task, with different cpu state, but share the same address space. Actually, all tasks share the same kernel space part, which are same as the idle context's kernel part. That's why no need to change address space(or mm) when switching normal process to kernel thread or between kernel threads.

In fact, the interrupt context is exactly the same type with kernel context and kernel-threads context: they do not rely on any normal process context. Interrupt is totally asynchronous, so in its context there is no assumption of interrupted task's context. I think this is why Robert Love says there are only two kind of contexts: process context and other.