Introduction: Why Does Execution Context Matter?

One of the most important concepts in Linux kernel programming is understanding where and how your kernel code is running at any given moment. This is called the kernel execution context.

When you write a Linux kernel module or a device driver, you are not writing a normal program. The code you write can execute in very different environments depending on what triggered it. Some code runs because a user application asked for something. Other code runs because a hardware device fired an interrupt signal. These two situations have completely different rules about what you can and cannot do.

Getting this wrong is one of the most common sources of kernel bugs, crashes, and system freezes. This free Linux kernel development tutorial explains it clearly from the ground up.

The Monolithic Kernel Architecture of Linux

Linux is a monolithic kernel. This means that the entire kernel — memory management, file systems, device drivers, network stack — all run in a single privileged address space called kernel space.

In contrast, a microkernel design would run many of these services in separate user-space processes. Linux chose the monolithic approach for performance. The trade-off is that a bug anywhere in the kernel can affect the entire system.

The important point is this: user-space processes run in unprivileged mode (Ring 3 on x86). When they need to do something that requires kernel access — like reading a file or sending data over a network — they make a system call, which causes the CPU to switch to privileged kernel mode (Ring 0).

What is Process Context in the Linux Kernel?

When a user-space process or thread makes a system call, the CPU saves the user-space register state and switches execution into kernel mode. From this point, the kernel code is running — but critically, it is running on behalf of that specific user process. This is called process context.

The System Call Path into Process Context

Here is the flow step by step:

1. A user-space thread calls something like read(fd, buf, count)
2. The C library wraps this in a software interrupt or syscall instruction
3. The CPU switches from Ring 3 (user) to Ring 0 (kernel)
4. The kernel’s system call handler takes over
5. The kernel runs the relevant driver or VFS code — all in process context
6. When done, it returns control back to user space

The key property of process context is that there is always a well-defined current process. The kernel uses a macro called current to access the task structure (struct task_struct) of the running process. In process context, current always points to something meaningful.

Another critical property: code running in process context is allowed to sleep. If the kernel needs to wait for something — like waiting for a disk read to complete — it can put the current process to sleep and let the scheduler run another process. This is perfectly safe in process context.

Code Example: Logging the Current Process Name in Process Context

Inside a kernel module’s file operation, you can access the name of the current process like this:

#include <linux/kernel.h>
#include <linux/sched.h>   /* for 'current' macro */

static ssize_t my_driver_read(struct file *filp, char __user *buf,
                               size_t count, loff_t *f_pos)
{
    /* 'current' is a macro pointing to the task_struct of the
     * process that called read() on our device file.
     * This is valid because we are in PROCESS CONTEXT.
     */
    pr_info("my_driver: read() called by process: %s (PID %d)\n",
            current->comm,    /* process name, max 16 chars */
            current->pid);    /* process ID */

    /* ... rest of read logic ... */
    return 0;
}

The current macro is a per-CPU variable that always points to the struct task_struct of the currently running task. It is valid only in process context. Accessing it in interrupt context can give you garbage or point to a random process that happened to be running when the interrupt fired.

What is Interrupt Context in the Linux Kernel?

Now here is where things get more complex — and more interesting. Your code does not always enter the kernel because a process asked for something. Hardware devices can demand attention at any time. When a keyboard key is pressed, when a network packet arrives, when a disk transfer completes — the hardware sends an interrupt signal to the CPU.

The CPU temporarily stops whatever it was doing, saves its current state, and jumps to a special function called the Interrupt Service Routine (ISR) or interrupt handler. This handler runs in interrupt context.

How Hardware Interrupts Work

Every hardware device is assigned an IRQ (Interrupt Request) line. When the device needs attention:

1. The device asserts its IRQ line to the interrupt controller (e.g. APIC on x86)
2. The interrupt controller signals the CPU
3. The CPU finishes its current instruction, saves registers onto the stack
4. The CPU switches to kernel mode and calls the registered interrupt handler
5. The ISR runs — in interrupt context
6. After the ISR returns, the CPU restores the saved state and resumes what it was doing

The most important rule in interrupt context is: you cannot sleep. The reason is straightforward. When an interrupt fires, it preempts whatever was running. The kernel cannot just put the interrupt handler to sleep — there is nothing to wake it up in a meaningful way, and it would hold up the interrupted task indefinitely. Sleeping in interrupt context causes a kernel panic.

Code Example: Registering and Writing an Interrupt Handler

Here is how you register an interrupt handler in a Linux kernel module:

#include <linux/interrupt.h>
#include <linux/kernel.h>

#define MY_IRQ   11         /* example IRQ number */
#define MY_DEV   "my_device"

/* The interrupt handler - runs in INTERRUPT CONTEXT */
static irqreturn_t my_irq_handler(int irq, void *dev_id)
{
    /* RULES in interrupt context:
     * - Do NOT sleep (no mutex_lock, no wait_event, no msleep, etc.)
     * - Do NOT access user space memory
     * - Keep this function SHORT and FAST
     * - Use GFP_ATOMIC if you need to allocate memory
     * - 'current' does NOT refer to any meaningful process here
     */

    pr_info("IRQ %d received - in INTERRUPT CONTEXT\n", irq);

    /* Acknowledge hardware, read status register, queue work, etc. */
    /* For longer work, use a tasklet or workqueue (bottom half) */

    return IRQ_HANDLED;
}

/* Called during module init - runs in PROCESS CONTEXT */
static int __init my_driver_init(void)
{
    int ret;

    /* request_irq() can sleep, so we call it from process context */
    ret = request_irq(MY_IRQ,           /* IRQ number */
                      my_irq_handler,   /* handler function */
                      IRQF_SHARED,      /* flags */
                      MY_DEV,           /* device name */
                      (void *)my_irq_handler); /* dev_id */
    if (ret) {
        pr_err("Failed to register IRQ %d: %d\n", MY_IRQ, ret);
        return ret;
    }

    pr_info("IRQ %d registered successfully\n", MY_IRQ);
    return 0;
}

static void __exit my_driver_exit(void)
{
    /* free_irq() must also be called from process context */
    free_irq(MY_IRQ, (void *)my_irq_handler);
    pr_info("IRQ %d released\n", MY_IRQ);
}

Process Context vs Interrupt Context: Side-by-Side Comparison

How to Detect the Current Execution Context in Your Kernel Code

Linux provides a kernel helper to check whether your code is running in interrupt context. This is useful for writing safe kernel modules and drivers that work correctly regardless of how they are called.

#include <linux/interrupt.h>

void my_kernel_function(void)
{
    if (in_interrupt()) {
        /* We are in interrupt context (hardirq or softirq) */
        pr_info("Running in INTERRUPT CONTEXT\n");
        /* Do NOT sleep. Use GFP_ATOMIC for allocations. */
    } else {
        /* We are in process context */
        pr_info("Running in PROCESS CONTEXT\n");
        pr_info("Current process: %s (PID %d)\n",
                current->comm, current->pid);
        /* Can sleep if needed. GFP_KERNEL is fine. */
    }
}

There are also more specific helpers:

• in_hardirq() — true if running in a hardware IRQ handler
• in_softirq() — true if running in a softirq or tasklet
• in_atomic() — true if sleeping is not allowed (includes spinlock-held sections)
• in_task() — true if running in a normal process/thread context

Top Halves and Bottom Halves: Splitting Interrupt Work

A well-written interrupt handler should do as little work as possible in interrupt context. The reason: while your ISR is running, the same interrupt (and often other interrupts) are disabled on the current CPU. If your handler takes too long, other hardware events get delayed and the system becomes unresponsive.

Linux solves this with a top-half / bottom-half design:

For new driver code, workqueues are the recommended mechanism for deferred work because they run in process context and can sleep. Tasklets are considered legacy in modern kernels (Linux 6.x onwards discourages new tasklet usage).

Common Mistakes and How to Avoid Them

Best Practices for Writing Context-Aware Kernel Code

• Always know your context. Before writing any kernel function, decide: will this be called from process context, interrupt context, or both?
• Use in_interrupt() defensively in shared utility functions to catch wrong usage early.
• Keep ISRs minimal. Do the bare minimum (ack the hardware, read status, wake up waiting process or schedule bottom half) and return.
• Prefer workqueues over tasklets for deferred work in modern kernels (Linux 5.x / 6.x).
• Use the correct memory allocation flag: GFP_KERNEL in process context, GFP_ATOMIC in interrupt or atomic context.
• Use the correct locking primitives: mutexes in process context only, spinlocks in interrupt context.
• Enable CONFIG_DEBUG_ATOMIC_SLEEP during development to catch sleeping-in-wrong-context bugs at runtime.

Key Takeaways

Frequently Asked Questions (FAQ)