What You Will Learn

Prerequisites

What Is a Critical Section, Really?

A critical section is any piece of code that touches data shared between more than one thread of execution — two processes calling into your driver at once, a kernel thread and an interrupt handler, or two CPU cores running the same driver function simultaneously. If that shared data can be read and written without protection, you get a race condition: the final result depends on timing rather than logic, and the bug may only appear once in a million calls, which makes it brutal to reproduce.

Mutex vs Spinlock: Picking the Right Lock for a Driver

The kernel gives you several locking primitives, and choosing the wrong one is one of the most common beginner mistakes in a driver’s read/write path. A mutex is a sleeping lock — a thread that cannot acquire it goes to sleep and is woken up later, which means it is safe to use in process context where blocking is allowed. A spinlock, on the other hand, busy-waits on other CPUs and must never be held across code that can sleep.

Declaring and Initializing a Mutex

Static declaration is the simplest approach for data that lives for the lifetime of the driver:

#include <linux/mutex.h>

/* Static initialization at compile time */
static DEFINE_MUTEX(devdata_lock);

If the lock lives inside a structure that is allocated dynamically (which is the norm for a per-device context), initialize it at runtime instead:

struct my_dev_ctx {
    struct device *dev;
    int            open_count;
    u64            bytes_read;
    u64            bytes_written;
    struct mutex   lock;
};

static int my_dev_probe(struct my_dev_ctx *ctx)
{
    mutex_init(&ctx->lock);
    return 0;
}

Locking and Unlocking Around Shared Driver Data

Once the mutex exists, wrap every access to the shared fields with mutex_lock() and mutex_unlock(). Here is an original, minimal read handler that safely reports how many bytes a device has served so far:

static ssize_t my_dev_read(struct file *filp, char __user *ubuf,
                            size_t count, loff_t *off)
{
    struct my_dev_ctx *ctx = filp->private_data;
    char reply[64];
    int  len;

    mutex_lock(&ctx->lock);
    len = scnprintf(reply, sizeof(reply), "bytes_read=%llu\n",
                     ctx->bytes_read);
    mutex_unlock(&ctx->lock);

    if (copy_to_user(ubuf, reply, len))
        return -EFAULT;

    return len;
}

Notice the lock is released before copy_to_user() is called on the freshly built local buffer. Keeping copy_to_user() outside the lock where possible avoids holding the mutex across a page fault, which keeps the critical section short.

A Practical Example: Guarding a Statistics Counter

Now let’s protect a write path that updates shared counters — a very common pattern in real drivers:

static ssize_t my_dev_write(struct file *filp, const char __user *ubuf,
                             size_t count, loff_t *off)
{
    struct my_dev_ctx *ctx = filp->private_data;

    /* ... copy_from_user() into a local kernel buffer here ... */

    mutex_lock(&ctx->lock);
    ctx->bytes_written += count;
    mutex_unlock(&ctx->lock);

    return count;
}

Any code path, including the release() (close) method, that reads or writes bytes_written, bytes_read, or open_count must take the same mutex. Protecting only some of the access points is a very common half-fix that still leaves a race.

Using the Modern guard(mutex) Cleanup Macro

Kernels from around 6.4 onward ship a scope-based cleanup helper in linux/cleanup.h that automatically unlocks the mutex when the enclosing block exits — including on early return or a goto out of the block. It removes an entire class of “forgot to unlock on the error path” bugs:

#include <linux/cleanup.h>
#include <linux/mutex.h>

static ssize_t my_dev_read_v2(struct file *filp, char __user *ubuf,
                               size_t count, loff_t *off)
{
    struct my_dev_ctx *ctx = filp->private_data;
    u64 snapshot;

    guard(mutex)(&ctx->lock);
    snapshot = ctx->bytes_read;
    /* lock is released automatically here, even on early return */

    return simple_read_from_buffer(ubuf, count, off, &snapshot,
                                    sizeof(snapshot));
}

Debugging Mutex Problems with Lockdep

The kernel’s lock validator, lockdep, is invaluable while developing driver locking. Enable it on a development kernel with:

CONFIG_DEBUG_MUTEXES=y
CONFIG_PROVE_LOCKING=y
CONFIG_DEBUG_LOCK_ALLOC=y

With these enabled, the kernel detects sleeping-while-locked violations, double-unlocks, and lock ordering inversions that could deadlock two drivers against each other, and it prints a detailed report to the kernel log instead of silently corrupting memory. Always run new driver code against a debug kernel before trusting it in production.

Real-World Use Cases

• Character and misc drivers protecting a per-device context struct shared across multiple open file descriptors
• Network drivers guarding statistics counters read by ethtool while packets are being transmitted
• Sensor and BLE peripheral drivers serializing access to a shared I2C/SPI transaction buffer
• Power management code protecting a device’s runtime PM state during suspend/resume races

Common Mistakes and Troubleshooting Tips

Best Practices

• Keep the critical section as short as possible — only the actual shared-data access, not I/O or lengthy computation
• Use guard(mutex) on modern kernels to guarantee unlock on every exit path
• Name your mutex fields clearly (for example, ctx_lock) so the protected data is obvious from the code around it
• Document, in a comment beside the struct field, which lock protects it
• Always test with CONFIG_PROVE_LOCKING enabled before shipping driver code

Performance Considerations

A mutex is heavier than a spinlock when contention is low, because sleeping and waking a task costs more than a short busy-wait. On modern kernels the mutex fast path (uncontended lock/unlock) is a cheap atomic operation, so the overhead only becomes visible under real contention. If a driver’s critical section is only a handful of instructions and is called from a context where sleeping is not required, a spinlock may be the better performance choice. For anything that can block — such as work involving copy_to_user() semantics indirectly, memory allocation with GFP_KERNEL, or I/O — a mutex is the only correct option.

Security Considerations

Unprotected shared state in a driver is not just a correctness bug, it can be a security issue. A race between two user processes opening the same device can lead to a use-after-free or a stale pointer being dereferenced, which is a classic path to local privilege escalation. Mutex-protecting every shared field, plus running with lockdep and KASAN enabled during development, closes off a meaningful class of kernel vulnerabilities before the driver ever reaches production.

Summary / Key Takeaways

• A critical section is any code touching data shared across threads, interrupts, or CPUs
• A mutex is a sleeping lock, safe only in process context, never in interrupt context
• Every access point to shared driver data — read, write, release, and any ioctl — must take the same lock
• The modern guard(mutex) macro removes missed-unlock bugs on newer kernels
• Always validate locking with lockdep on a debug kernel before shipping

Conclusion

Mutex locks are the workhorse synchronization primitive for process-context code in Linux drivers, and getting comfortable with them is a core skill in any free linux kernel development course. Once you can reliably identify a driver’s critical sections and wrap them correctly — including on error paths — you have removed one of the most common sources of kernel instability. In the next lecture of this free embedded systems course, we go one level deeper and look at the different mutex lock API variants: the interruptible, trylock, killable, and io flavors, and exactly when each one is the right tool.

Frequently Asked Questions