IRQ-Safe Spinlocks for Data Protection

1. The Classic Deadlock: Interrupts and Spinlocks

Let's start by revisiting the scenario that makes this topic so critical. In a preemptive, multi-core system, you have two primary execution contexts that can interact with your driver's data:

• Process Context: This is code executing on behalf of a user application, like a read() or ioctl() system call. It can be preempted and is allowed to sleep.
• Interrupt Context: This is code executing in an Interrupt Service Routine (ISR) in response to a hardware event. It cannot sleep and typically preempts any process context code running on the same CPU.

The conflict arises when process context holds a lock and an interrupt fires on the same CPU.

The following video from our last lesson on spinlock fundamentals perfectly illustrates this deadlock. Watching it again will set the stage for understanding the Linux-specific solution.

This video demonstrates two key points:

1. The race is not just between different CPUs in an SMP system, but also between different execution contexts on the same CPU.
2. The fundamental solution is to disable interrupts on the local CPU before acquiring the lock. This ensures an ISR cannot preempt the critical section and try to acquire the same lock.

2. The Solution: spin_lock_irqsave

The Linux kernel provides a specific set of functions designed to implement this "disable interrupts and lock" pattern safely and robustly. The most important of these are spin_lock_irqsave and spin_unlock_irqrestore.

Let's break down exactly what this pair of functions does:

spin_lock_irqsave(spinlock_t *lock, unsigned long flags);

1. First, it examines the CPU's interrupt status register and saves its current state into the flags variable you provide. This variable acts as a ticket to remember if interrupts were enabled or disabled before you called the function.
2. Next, it disables interrupts on the local CPU.
3. Finally, it acquires the spinlock, spinning if necessary.

spin_unlock_irqrestore(spinlock_t *lock, unsigned long flags);

1. It releases the spinlock, making it available to other threads.
2. It then restores the interrupt status on the local CPU using the state saved in your flags variable.

This "save and restore" mechanism is more robust than simply re-enabling interrupts. If your code was called from a context where interrupts were already disabled (e.g., inside another ISR), spin_unlock_irqrestore correctly leaves them disabled. A simpler function that just re-enables them would introduce a bug.

3. Practical Implementation in a Device Driver

Let's apply this to a common device driver pattern: an ISR receives data from hardware and places it into a buffer, while a read() file operation (in process context) consumes data from that buffer.

// Define the shared data and the lock
struct my_device_data {
    char circ_buf[1024];
    unsigned int head;
    unsigned int tail;
    // ... other data
};

struct my_device_data g_dev_data;
DEFINE_SPINLOCK(g_dev_lock); // Statically initialize the spinlock

// --- Interrupt Context ---
static irqreturn_t my_irq_handler(int irq, void *dev_id) {
    unsigned long flags;
    char received_char;
    
    // Acquire lock and disable local interrupts
    spin_lock_irqsave(&g_dev_lock, &flags);
    
    // CRITICAL SECTION
    received_char = read_hw_register();
    g_dev_data.circ_buf[g_dev_data.head] = received_char;
    g_dev_data.head = (g_dev_data.head + 1) % 1024;
    // END CRITICAL SECTION
    
    // Release lock and restore interrupt state
    spin_unlock_irqrestore(&g_dev_lock, &flags);
    
    return IRQ_HANDLED;
}

// --- Process Context ---
static ssize_t my_read(struct file *filp, char __user *buf, size_t len, loff_t *off) {
    unsigned long flags;
    size_t bytes_to_copy = 0;
    
    // Acquire lock and disable local interrupts
    spin_lock_irqsave(&g_dev_lock, &flags);
    
    // CRITICAL SECTION
    // Calculate how many bytes can be copied from g_dev_data to the user buffer `buf`
    // ...
    // Update g_dev_data.tail
    // END CRITICAL SECTION
    
    // Release lock and restore interrupt state
    spin_unlock_irqrestore(&g_dev_lock, &flags);
    
    // Safely copy data to user space (this can sleep, so it MUST be outside the lock)
    if (copy_to_user(buf, /*...source...*/, bytes_to_copy)) {
        return -EFAULT;
    }
    
    return bytes_to_copy;
}

Notice that both the ISR and the process context code use the exact same _irqsave/_irqrestore pair. This is the standard, safe, and recommended practice.

For a more detailed walkthrough and explanation, the official kernel documentation is an excellent resource.

4. Interview Deep Dive: Spinlock API Variants

A good follow-up question in an interview is to ask you to compare the different spinlock variants. Your ability to explain the nuances demonstrates a mature understanding of kernel concurrency.

The following tutorial provides a good breakdown of these different "approaches."

The key takeaway, often repeated by senior kernel developers and summarized in the "Unreliable Guide To Locking", is:

When in doubt, use spin_lock_irqsave.

It is the most robust and will always do the right thing, even if it's sometimes slightly less performant than a more specialized variant like spin_lock_bh. In an interview, advocating for the safest default is a strong position.

Conclusion

You have now dissected the most critical pattern for safe data sharing between process and interrupt contexts in the Linux kernel. This is a non-negotiable skill for anyone writing device drivers or working deep in the OS.

Key Takeaways:

• Protecting data shared between process context and an ISR requires preventing both multi-core race conditions and same-core deadlocks.
• spin_lock_irqsave is the tool for this job. It acquires a spinlock (for SMP safety) and disables local interrupts (for same-CPU safety).
• The flags parameter is crucial for _irqsave/_irqrestore to correctly handle nested locking or calls from contexts where interrupts might already be disabled.
• While other variants like spin_lock_bh and spin_lock_irq exist for specific situations, spin_lock_irqsave is the most general and safest choice.

Preview of the Next Lesson:

Spinlocks are essential, but they have a performance cost, especially under contention. When one CPU holds a lock, all other CPUs trying to acquire it are spinning and wasting cycles. What if there was a way to allow multiple readers to access data without any locks at all, while still allowing a writer to safely update it? In our next lesson, we will explore a powerful and highly-performant synchronization mechanism that enables this: Read-Copy-Update (RCU).