Prerequisites

Preemptible Kernels and Data Races on a Single CPU

Most distribution kernels today ship with CONFIG_PREEMPT enabled, meaning the kernel itself can be interrupted mid-task and switched to a different, higher-priority piece of work — even while running kernel code, not just user-space code. Imagine your driver’s read handler is halfway through updating a shared structure when the scheduler decides to preempt it and run a different process that happens to call the very same read handler. That second invocation now sees a half-updated structure. This is a genuine data race, and it can occur on a machine with only one CPU core.

Blocking Calls Inside a Critical Section

A blocking call puts the calling task to sleep until some event occurs — waiting for disk I/O, a semaphore, or a network packet are common examples. If your code calls a blocking function while still holding shared data mid-update, the kernel scheduler is free to run a completely different task on that CPU in the meantime, and that task may execute the very same code path. By the time your original task wakes up and resumes, the shared data may have already changed underneath it.

Hardware Interrupts and Data Races

Hardware interrupts have the highest priority on Linux — they can preempt any code, including kernel code, on the CPU where they fire. If your process-context code is mid-way through updating shared data and an interrupt fires on that same CPU, the interrupt handler runs immediately. If that handler touches the same shared data your process context was updating, you have a race between “normal” driver code and interrupt code — and this is one of the most common sources of subtle driver bugs.

Whether interrupt handling and process context actually share data is a question only you, the driver author, can answer by inspecting your own code. If they do, that shared data must be protected against races between process context and interrupt context — not just between two processes.

Choosing the Right Locking Primitive

The Linux kernel offers several tools for protecting critical sections. Picking the wrong one either fails to fix the race or destroys performance. Here is an updated selection guide for current kernels:

Below is an original example showing the correct fix for the broken counter shown in Part 1 — protecting it with spin_lock_irqsave() because the counter may also be touched from an interrupt handler:

#include <linux/module.h>
#include <linux/spinlock.h>

static int open_count;
static DEFINE_SPINLOCK(open_count_lock);

static int demo_open(struct inode *inode, struct file *file)
{
    unsigned long flags;

    spin_lock_irqsave(&open_count_lock, flags);
    open_count = open_count + 1;
    spin_unlock_irqrestore(&open_count_lock, flags);

    pr_info("demo: device opened %d times\n", open_count);
    return 0;
}

spin_lock_irqsave() disables local interrupts before taking the lock and restores the previous interrupt state afterwards, which is exactly what you need when the same data can be touched from an interrupt handler on the same CPU.

What’s New: Tasklets Are Being Retired

If you have read older Linux kernel books, you’ll have come across tasklets as the classic mechanism for deferring work out of a hardware interrupt handler. That guidance is now outdated. Starting with kernel 6.9, the tasklet API was formally marked deprecated in favour of a new BH (bottom-half) workqueue mechanism, because tasklets had long-standing design flaws around how they track pending work. New driver code should schedule deferred work using queue_work() on a BH workqueue (or a regular workqueue / threaded IRQ handler) instead of tasklet_schedule(). If you maintain older code, plan a migration — tasklets still work today, but they are on their way out of the kernel.

Real-World Use Cases

Common Mistakes and Troubleshooting

Best Practices

• Keep every critical section as short as possible — lock, do the minimum work, unlock.
• Never call a blocking/sleeping function while holding a spinlock.
• If data is touched from an interrupt handler, use the _irqsave / _irqrestore lock variants.
• Prefer atomic types for simple counters instead of a full lock.
• Enable lockdep and KCSAN in your development kernel — don’t wait for production bug reports.
• Migrate any tasklet-based deferred work to BH workqueues in new drivers.

Performance Considerations

Spinlocks are cheap when contention is low but waste CPU cycles busy-waiting under heavy contention. Mutexes avoid busy-waiting but cost more to acquire/release due to scheduler involvement. RCU offers the best read-side performance for read-heavy data but adds complexity on the write side. Always measure under realistic concurrent load before assuming a locking choice is “good enough.”

Security Considerations

A missed _irqsave variant, or a race between interrupt and process context, is not just a correctness bug — it is precisely the kind of narrow timing window that has historically been exploited for local privilege escalation in the Linux kernel. Treat interrupt-context locking as a security-critical detail, not an optional refinement.

Summary / Key Takeaways

• Preemption can cause data races even on a single CPU.
• Blocking calls inside a critical section let other tasks run and touch the same data.
• Hardware interrupts can preempt any process-context code, including kernel code.
• Use spinlocks for short, non-sleeping sections; mutexes when you may need to sleep.
• Tasklets are deprecated since kernel 6.9 — prefer BH workqueues in new code.
• PREEMPT_RT has been mainline since kernel 6.12, raising the bar for locking discipline.

Conclusion

Data races in Linux device driver code rarely come from obviously wrong logic — they come from an unprotected assumption about who else might be touching the same data, whether that’s another CPU, a preempting task, or a hardware interrupt. Combine the mental model from this free Linux device drivers course with the right locking primitive for each situation, and you’ll avoid the vast majority of concurrency bugs that plague first-time kernel and driver developers.

FAQ: Preemption, Interrupts and Locking in Linux Drivers