• Basic C programming knowledge
• A working Linux kernel module (LKM) written and loaded at least once (insmod / rmmod)
• Familiarity with the idea of a character device driver is helpful but not mandatory
• A Linux machine or VM running kernel 6.1 or later to follow along

You can declare and initialize a mutex statically with a single macro, or initialize one dynamically at runtime:

#include <linux/mutex.h>

/* Static initialization — done at compile time */
static DEFINE_MUTEX(my_data_lock);

/* Dynamic initialization — typically used inside a struct */
struct my_device_context {
    struct mutex lock;
    int          shared_value;
};

static int __init my_driver_init(void)
{
    mutex_init(&my_ctx->lock);
    return 0;
}

mutex_lock(&my_ctx->lock);
/* critical section: touch shared_value here, and only here */
my_ctx->shared_value++;
mutex_unlock(&my_ctx->lock);

mutex_lock() puts the calling task into an uninterruptible sleep if the lock is already held. That means the task will not respond to signals (not even Ctrl+C) until the lock becomes free.

int ret = mutex_lock_interruptible(&my_ctx->lock);
if (ret != 0)
    return -ERESTARTSYS;   /* woken up by a signal, not by the lock */

/* critical section */
mutex_unlock(&my_ctx->lock);

Use this variant on any code path that user space can reach directly (for example inside a driver’s read() or write() file operation), so that a blocked user process can still be interrupted with Ctrl+C instead of hanging forever.

if (!mutex_trylock(&my_ctx->lock)) {
    /* lock was busy — decide what to do instead of waiting */
    return -EBUSY;
}
/* lock acquired, proceed */
mutex_unlock(&my_ctx->lock);

static void __exit my_driver_exit(void)
{
    mutex_destroy(&my_ctx->lock);
}

mutex_destroy() marks the mutex as unusable. On a debug kernel built with CONFIG_DEBUG_MUTEXES, forgetting this call — or destroying a mutex that is still locked — will be flagged loudly in the kernel log, which is exactly the kind of bug you want caught early during development rather than in production.

• Keep critical sections as short as possible — do the minimum work while holding the lock.
• Never call functions that might sleep for a long time (like blocking I/O) while holding a mutex unless it’s unavoidable.
• Always pair every mutex_lock() with exactly one mutex_unlock() on every possible code path, including error paths.
• Prefer mutex_lock_interruptible() on any path reachable from user space.
• Always call mutex_destroy() during cleanup, even though it is a no-op on non-debug kernels.
• Document what each mutex protects directly above its declaration.

• The real-time preemption work (PREEMPT_RT) was merged into the mainline kernel with the 6.12 release, after being an out-of-tree patch set for close to two decades. On a kernel built with full real-time preemption, spinlocks internally behave more like sleeping locks, which makes disciplined mutex usage in driver code even more important.
• Lockdep (the kernel’s built-in lock-dependency validator) has continued to receive accuracy improvements, catching more classes of potential deadlocks between mutexes automatically during development.
• Wound-wait mutexes (struct ww_mutex) remain the recommended primitive for cases where multiple locks of the same class must be taken in varying order (common in graphics and memory-management subsystems), avoiding classic lock-ordering deadlocks.

Q1. What is a mutex lock in the Linux kernel used for?
It is used to protect shared writable data — such as global variables or a driver’s context structure — from being accessed by more than one thread of execution at the same time.

Q2. Can I use a mutex inside an interrupt handler?
No. Mutexes can put the calling task to sleep, and interrupt context is not allowed to sleep. Use a spinlock (with the correct IRQ-safe variant) inside interrupt handlers instead.

Q3. What is the difference between mutex_lock() and mutex_lock_interruptible()?
mutex_lock() sleeps uninterruptibly and ignores signals while waiting. mutex_lock_interruptible() can be woken up by a signal and returns a non-zero error code in that case, which is safer on any path reachable from user space.

Q4. Is a Linux kernel mutex recursive?
No. Locking the same mutex twice from the same thread without unlocking it first will deadlock. If you need that pattern, redesign your locking rather than reaching for a recursive lock.

Q5. When should I use a spinlock instead of a mutex?
Use a spinlock when the critical section is very short, or when the code must run in a context that cannot sleep, such as an interrupt handler.

Q6. Do I really need to call mutex_destroy()?
Yes, as a matter of correct practice. It is a no-op on a normal production kernel but becomes an active check on a debug kernel built with CONFIG_DEBUG_MUTEXES, helping you catch misuse early.

Q7. What tool helps catch mutex-related deadlocks during development?
Lockdep, the kernel’s built-in locking correctness validator, enabled through CONFIG_PROVE_LOCKING, is the standard tool for this.

Q8. Is this tutorial part of a free Linux kernel development course?
Yes. This lecture is part of EmbeddedPathashala’s free Linux kernel development course, free Linux device drivers course, and free embedded systems course.