Kernel Synchronization: Spinlocks, RCU, Atomics, Barriers

In userspace, when two threads conflict on a mutex, the loser sleeps — the OS scheduler parks it and gives the CPU to someone else. This is fine when you are a web server. In the kernel, large swaths of code cannot sleep:

• Interrupt handlers (hardirq context) run on the current CPU's stack with interrupts disabled. If they block, the CPU is wedged forever.
• Softirq / tasklet context is similarly non-sleepable.
• Spinlock critical sections must complete without sleeping, or the system deadlocks.
• Atomic context (any code that has called preempt_disable() or local_irq_disable()) cannot call anything that might sleep.

The kernel therefore has two broad categories of locks: sleeping locks (mutexes, semaphores, rw_semaphore) that can only be taken from process context where sleeping is legal, and spinning locks (spinlocks, rwlocks) that burn CPU cycles waiting and can be used anywhere — including interrupt handlers.

A second difference is priority inversion. The kernel's real-time (PREEMPT_RT) patches flip some spinlocks into sleeping mutexes to bound latency, which shows that even this division is not permanent — it is driven by scheduling policy.

A third brutal reality: the kernel runs on weakly-ordered hardware. x86 gives you a fairly strong memory model, but ARM and RISC-V do not. A store on CPU 0 might not be visible on CPU 1 until you emit a barrier instruction. The kernel's synchronization primitives embed the right barriers so that callers do not have to think about this — but when you write new locking code, you must.

/* This is WRONG — sleeping inside a spinlock */
static DEFINE_SPINLOCK(my_lock);

void bad_function(void)
{
    spin_lock(&my_lock);        /* interrupts disabled, preemption off */
    kmalloc(4096, GFP_KERNEL);  /* BUG: GFP_KERNEL may sleep! */
    spin_unlock(&my_lock);
}

/* CORRECT: use GFP_ATOMIC in atomic context */
void good_function(void)
{
    spin_lock(&my_lock);
    kmalloc(4096, GFP_ATOMIC);  /* never sleeps; may fail */
    spin_unlock(&my_lock);
}

The simplest building block of kernel synchronization is the atomic operation: a read-modify-write that the hardware guarantees completes without interruption on that CPU, and (with barriers) is visible to all other CPUs in a defined order.

Linux wraps these in atomic_t (32-bit) and atomic64_t (64-bit). The implementation maps to a single locked instruction on x86 (lock xadd, lock cmpxchg, etc.) and to the ldxr/stxr exclusive-access loop on ARM64.

Key API:

atomic_t v = ATOMIC_INIT(0);
atomic_set(&v, 5);           // v = 5 (not SMP-safe for compound ops)
atomic_read(&v);             // read current value
atomic_inc(&v);              // v++, atomic
atomic_dec_and_test(&v);     // --v; return (v == 0)
atomic_add(n, &v);           // v += n
atomic_cmpxchg(&v, old, new);// if v==old: v=new; return old

Why atomic_read is not just v.counter: On platforms where int access is not naturally atomic (rare today but must be portable), a plain read could tear. More importantly, atomic_read implies a compiler barrier — the compiler cannot cache the value in a register across the read.

Atomics do NOT replace locks for compound operations. atomic_inc(&v); if (atomic_read(&v) == 1) { ... } is still racy because another CPU can increment between the two operations. Atomics are correct for: reference counting, statistics counters, flags, and the compare-and-swap primitive used to build lock-free structures.

Memory ordering of atomics: By default, atomic_inc on x86 is a fully-ordered locked instruction. On ARM64, the kernel uses staddl (acquire-release). For performance, the kernel exposes relaxed variants: atomic_inc_relaxed, atomic_add_return_acquire, etc., which map to weaker barrier instructions where the architecture supports them.

/* Reference counting — the canonical use of atomic_t */
struct my_object {
    atomic_t refcount;
    /* ... other fields ... */
};

void my_get(struct my_object *obj)
{
    atomic_inc(&obj->refcount);
}

void my_put(struct my_object *obj)
{
    /* dec_and_test: returns true when counter hits zero */
    if (atomic_dec_and_test(&obj->refcount))
        kfree(obj);  /* last reference dropped */
}

Modern CPUs and compilers reorder memory operations for performance. This is invisible in single-threaded code but catastrophic in SMP (multi-processor) code without explicit barriers.

The three culprits:

1. Compiler reordering — the compiler may move a store before a load if it thinks the locations do not alias.
2. CPU out-of-order execution — the CPU may retire stores to its store buffer before they reach the cache-coherent domain.
3. CPU store-load reordering — on weakly-ordered ISAs (ARM, RISC-V, POWER), a load can be satisfied from the store buffer of a different CPU's pending writes if the cache line is shared.

The Linux barrier API:

On x86, smp_rmb() and smp_wmb() compile to just a compiler barrier (x86 already orders loads and stores among themselves). smp_mb() compiles to mfence or a locked instruction. On ARM64, they compile to dmb ish (data memory barrier, inner-shareable domain).

Acquire/release pairs are the preferred modern idiom. A release store (smp_store_release) guarantees all prior operations are visible before the store. An acquire load (smp_load_acquire) guarantees the load completes before any subsequent operation. Used together they form a happens-before edge: anything done before the release is seen after the acquire.

Classic example — flag-based communication:

CPU 0 (writer):           CPU 1 (reader):
  data = 42;              while (!READ_ONCE(flag)) ;
  smp_wmb();              smp_rmb();
  WRITE_ONCE(flag, 1);    printk("%d\n", data); // must print 42

Without smp_wmb() on CPU 0, the flag store could become globally visible before the data store on a weakly-ordered CPU, and the reader would see flag==1 but stale data.

/* Producer/consumer with explicit barriers (educational — 
   prefer smp_store_release/smp_load_acquire in real code) */

static int shared_data __cacheline_aligned;
static int ready;  /* flag */

void producer(void)
{
    shared_data = 42;       /* 1. write payload */
    smp_wmb();              /* 2. ensure payload visible before flag */
    WRITE_ONCE(ready, 1);   /* 3. publish */
}

void consumer(void)
{
    while (!READ_ONCE(ready)) /* spin until flag seen */
        cpu_relax();
    smp_rmb();              /* ensure flag load completes before data load */
    pr_info("data = %d\n", shared_data); /* guaranteed to see 42 */
}

A spinlock is a lock that, when contended, repeatedly tests the lock variable in a tight loop ("spins") rather than sleeping. This makes it usable in contexts where sleeping is illegal — including interrupt handlers.

How it works on x86: The spin_lock implementation ultimately executes something like:

1:  lock bts dword [rdi], 0    ; atomically set bit 0; CF = old value
    jc 1b                       ; if was set (locked), spin

On ARM64 it uses the load-exclusive / store-exclusive (ldaxr/stxr) loop. Modern kernels use a ticket spinlock (or on ARM64, a queued spinlock / qspinlock) to ensure fairness — CPUs acquire the lock in the order they arrived, preventing starvation.

The API:

DEFINE_SPINLOCK(lock);        /* static allocation */
spinlock_t lock;
spin_lock_init(&lock);        /* dynamic allocation */

spin_lock(&lock);             /* acquire; disables preemption */
spin_unlock(&lock);           /* release; re-enables preemption */

spin_lock_irqsave(&lock, flags);   /* also disables local IRQs */
spin_unlock_irqrestore(&lock, flags);

spin_lock_irq(&lock);         /* disable IRQs (don't save flags) */
spin_unlock_irq(&lock);

spin_lock_bh(&lock);          /* disable softirq only */
spin_unlock_bh(&lock);

Which variant to use:

• spin_lock / spin_unlock: safe when neither your code nor anything that shares this lock runs in interrupt context.
• spin_lock_irqsave: use when the lock is shared with an interrupt handler. This disables local interrupts so the handler cannot fire and try to take the same lock (which would deadlock, since spinlocks are not reentrant).
• spin_lock_bh: use when the lock is shared with a softirq/tasklet but not a hardirq.

Critical rules:

1. Never sleep inside a spinlock critical section.
2. Never call a function that might sleep (kmalloc with GFP_KERNEL, copy_from_user, msleep, schedule) while holding a spinlock.
3. Keep critical sections short. Every nanosecond you hold a spinlock, other CPUs wanting it are burning cycles.
4. Spinlocks are not reentrant. Taking a lock you already hold = deadlock.

Read/write spinlocks (rwlock_t) allow multiple concurrent readers but exclusive writers, using read_lock/read_unlock and write_lock/write_unlock. In practice these are less common now because RCU is preferred for read-heavy workloads.

/* Driver with IRQ-safe spinlock protecting a hardware FIFO */
struct my_dev {
    spinlock_t  lock;
    struct list_head tx_queue;
};

/* Called from process context (write syscall) */
int my_enqueue(struct my_dev *dev, struct packet *pkt)
{
    unsigned long flags;

    /* IRQ save: the tx interrupt handler also touches tx_queue */
    spin_lock_irqsave(&dev->lock, flags);
    list_add_tail(&pkt->list, &dev->tx_queue);
    spin_unlock_irqrestore(&dev->lock, flags);
    return 0;
}

/* Called from hardirq context (tx complete interrupt) */
irqreturn_t my_irq_handler(int irq, void *data)
{
    struct my_dev *dev = data;
    struct packet *pkt;

    spin_lock(&dev->lock);  /* no irqsave needed: IRQs already off in hardirq */
    pkt = list_first_entry_or_null(&dev->tx_queue, struct packet, list);
    if (pkt)
        list_del(&pkt->list);
    spin_unlock(&dev->lock);

    if (pkt)
        kfree(pkt);
    return IRQ_HANDLED;
}

RCU is the most intellectually beautiful synchronization primitive in the Linux kernel. Its core insight: if readers never modify shared data and are short enough, you can let them run completely lock-free, and defer the destruction of old data until all active readers finish.

The three rules of RCU:

1. Readers use rcu_read_lock() / rcu_read_unlock() (which on non-PREEMPT kernels just disables preemption — zero overhead on the hot path). They dereference RCU-protected pointers with rcu_dereference().
2. Writers never modify data in place. They: (a) copy the object, (b) modify the copy, (c) atomically publish the new pointer with rcu_assign_pointer(), (d) call synchronize_rcu() (or call_rcu() for async), which waits until all CPUs have passed through a quiescent state — a point where no CPU is inside an RCU read-side critical section. Only then is the old object freed.
3. The grace period: the interval between the pointer update and when the old object can be freed. After one grace period, no reader can hold a reference to the old object (because RCU read-side critical sections cannot span a quiescent state — a context switch, on preemptible kernels; or a schedule-out, on PREEMPT_RT).

Why this is so powerful: On a machine with 256 cores and a read-mostly data structure (like the routing table, which is read billions of times per second and updated rarely), replacing a global rwlock with RCU can give a 100x throughput improvement on the read side, because readers on all 256 cores proceed simultaneously with no cache-line contention.

The cost: Writers are slower (copy + grace period wait). The grace period can be milliseconds on a loaded system. RCU read-side sections must not sleep (on non-PREEMPT kernels) and must be short. Debugging RCU misuse is hard — rcu_dereference() without rcu_read_lock() is a common bug that lockdep/sparse can catch.

Variants:

• synchronize_rcu() — synchronous, blocks until grace period.
• call_rcu(&head, func) — async; func is called after grace period.
• rcu_barrier() — wait for all pending call_rcu callbacks.
• SRCU (Sleepable RCU) — allows sleeping in read-side critical sections at the cost of per-SRCU-domain state.
• QRCU, Tasks RCU — for even more specialized contexts.

/* RCU-protected global pointer to a config struct */
struct config {
    int timeout;
    char name[64];
};

static struct config __rcu *global_cfg;  /* __rcu annotation for sparse */

/* READER — runs on hot path, potentially millions of times/sec */
void read_timeout(void)
{
    struct config *cfg;
    int t;

    rcu_read_lock();                        /* disable preemption */
    cfg = rcu_dereference(global_cfg);      /* load pointer safely */
    t = cfg->timeout;                       /* read field while lock held */
    rcu_read_unlock();                      /* re-enable preemption */

    pr_info("timeout = %d\n", t);
}

/* WRITER — called rarely (config reload) */
void update_config(int new_timeout)
{
    struct config *old_cfg, *new_cfg;

    new_cfg = kmalloc(sizeof(*new_cfg), GFP_KERNEL);

    /* Copy old values, modify copy */
    old_cfg = rcu_dereference_protected(global_cfg,
                  lockdep_is_held(&my_writer_mutex));
    *new_cfg = *old_cfg;           /* copy */
    new_cfg->timeout = new_timeout; /* modify copy */

    rcu_assign_pointer(global_cfg, new_cfg); /* publish atomically */

    synchronize_rcu();  /* wait: all readers now see new_cfg or will */
    kfree(old_cfg);     /* safe to free: no reader holds old pointer */
}

A seqlock (sequence lock) is optimized for the case where writes are rare but must be fast, and readers can tolerate retrying. The canonical use in the kernel is jiffies_64 and xtime (wall clock time) — the timer interrupt updates them frequently but reads are also frequent.

How it works:

• A sequence counter is embedded in the lock.
• Writers take an exclusive spinlock, increment the counter (making it odd = write in progress), do the update, increment again (making it even = done).
• Readers sample the counter before and after reading. If the counter changed (or was odd during the read), a writer was active — the reader retries. No reader-side lock at all.

Tradeoffs:

• Read-side is wait-free in the uncontended case (just two reads of the counter).
• Readers may loop indefinitely if writers are very frequent — starvation is theoretically possible but rare in practice.
• The data being protected must be copyable atomically enough for the retry to be safe (no pointers that could be freed mid-read — use RCU for pointer-heavy structures).
• Writers can never be starved by readers (contrast with rwlock where a flood of readers can lock out a writer).

API:

seqlock_t sl = SEQLOCK_UNLOCKED;

// Writer:
write_seqlock(&sl);
/* modify data */
write_sequnlock(&sl);

// Reader:
unsigned seq;
do {
    seq = read_seqbegin(&sl);
    /* read data into local copies */
} while (read_seqretry(&sl, seq));

/* Seqlock protecting a 64-bit timestamp on a 32-bit system
   (where a 64-bit read is not atomic without a lock) */

static seqlock_t time_lock = SEQLOCK_UNLOCKED;
static u64 current_ns;

/* Called from timer interrupt — must be fast */
void update_time(u64 ns)
{
    write_seqlock(&time_lock);
    current_ns = ns;
    write_sequnlock(&time_lock);
}

/* Called from any context — readers retry if interrupted by writer */
u64 get_time_ns(void)
{
    unsigned seq;
    u64 ns;

    do {
        seq = read_seqbegin(&time_lock);
        ns  = current_ns;          /* may be torn if writer active */
    } while (read_seqretry(&time_lock, seq)); /* retry if seq changed */

    return ns;  /* guaranteed consistent */
}

The best lock is no lock at all. Per-CPU variables give each CPU its own private copy of a variable, eliminating all contention. There is no sharing, therefore no synchronization needed between CPUs.

This is used heavily for: CPU-local statistics counters, per-CPU memory allocator caches (slab/slub), the scheduler's run queues, and the current task pointer.

Declaration:

DEFINE_PER_CPU(int, my_counter);
/* or dynamically: alloc_percpu(int) */

Access:

/* Safely read/write THIS CPU's copy */
int val = get_cpu_var(my_counter);  /* disables preemption */
get_cpu_var(my_counter)++;          /* modify */
put_cpu_var(my_counter);            /* re-enables preemption */

/* Raw access (caller ensures no preemption/migration) */
this_cpu_inc(my_counter);           /* optimized; uses this_cpu_* accessors */
this_cpu_add(my_counter, 5);

/* Access another CPU's copy (for aggregation) */
int cpu;
long total = 0;
for_each_online_cpu(cpu)
    total += per_cpu(my_counter, cpu);

The preemption danger: If a task reads get_cpu_var(x), then gets preempted and migrated to CPU 1, and then writes, it writes to CPU 0's variable while running on CPU 1 — a bug. get_cpu_var prevents this by disabling preemption. The this_cpu_* accessors are for code that has already guaranteed no migration (e.g., inside a spinlock-protected section or with preemption already disabled).

Memory layout: Per-CPU variables are allocated in a contiguous block per CPU at boot, with each CPU's block placed on a different NUMA node if possible. The kernel uses segment-register tricks on x86 (%gs base) or a dedicated tp register on RISC-V/ARM64 to efficiently address the current CPU's section.

/* Per-CPU stats counter — zero-overhead on the fast path */
DEFINE_PER_CPU(unsigned long, packets_received);

/* Called on every received packet — must be blazing fast */
void count_packet(void)
{
    /* this_cpu_inc is a single instruction on x86 (no lock prefix needed!) */
    this_cpu_inc(packets_received);
}

/* Called from /proc read — aggregates across all CPUs */
unsigned long total_packets(void)
{
    unsigned long total = 0;
    int cpu;

    for_each_online_cpu(cpu)
        total += per_cpu(packets_received, cpu);

    return total;
}

Both mutex and spinlock protect critical sections, but they make opposite trade-offs:

The kernel mutex API (not pthread_mutex — a different, kernel-internal type):

DEFINE_MUTEX(my_mutex);
mutex_lock(&my_mutex);      /* may sleep */
mutex_unlock(&my_mutex);
mutex_trylock(&my_mutex);   /* non-blocking; returns 1 if acquired */
mutex_lock_interruptible(&my_mutex); /* returns -EINTR if signal arrives */

Decision rule:

• Use spinlock when: the critical section is short (< a few microseconds), the code might run in interrupt context, or you need the lock only on a single CPU path where spinning is cheaper than a context switch.
• Use mutex when: the critical section might sleep (I/O, kmalloc with GFP_KERNEL, copy_from_user, condition waits), or when long hold times are expected.
• Use RCU when: the data structure is read-mostly and you can tolerate the write complexity.
• Use per-CPU when: each CPU logically has its own instance of the data.
• Use atomics when: you need a single counter or flag with no compound operations.

A common mistake: using a spinlock for a long critical section because "mutexes are too slow." A mutex that sleeps releases the CPU; a spinlock that spins for 10 ms holds the CPU hostage, starving every other thread on that core.

/* A file-system-style object with two different locks:
   - spinlock for the fast-path inode cache lookup (IRQ-safe)
   - mutex for the slow-path disk read (may sleep) */
struct my_inode {
    spinlock_t   cache_lock;  /* protects: cached_data, cache_valid */
    struct mutex io_mutex;    /* protects: disk I/O in progress */
    char        *cached_data;
    bool         cache_valid;
};

char *fast_read(struct my_inode *ino)
{
    char *data = NULL;
    spin_lock(&ino->cache_lock);
    if (ino->cache_valid)
        data = ino->cached_data;
    spin_unlock(&ino->cache_lock);
    return data;              /* NULL means: go to slow path */
}

char *slow_read(struct my_inode *ino)
{
    mutex_lock(&ino->io_mutex);  /* may sleep waiting for disk */
    /* ... read from disk ... */
    spin_lock(&ino->cache_lock);
    ino->cache_valid = true;
    spin_unlock(&ino->cache_lock);
    mutex_unlock(&ino->io_mutex);
    return ino->cached_data;
}

lockdep is a runtime lock dependency checker built into the kernel (enabled with CONFIG_LOCKDEP=y, automatically enabled when CONFIG_PROVE_LOCKING=y). It is one of the most impressive pieces of kernel infrastructure ever written.

What it does: lockdep tracks every lock acquisition and builds a directed graph of lock-acquisition order. If CPU 0 ever does A → B (acquires A then B) and CPU 1 does B → A, lockdep immediately prints a deadlock warning — even if the actual deadlock has not happened yet. It catches the potential for a circular lock dependency the first time the ordering is observed.

What it catches:

• AB-BA deadlocks (classic deadlock)
• Taking a sleeping lock (mutex) while holding a spinlock
• Acquiring a lock in interrupt context that is also acquired in process context without proper irqsave
• Lock-order inversion across interrupt boundaries
• Taking an already-held non-reentrant lock

Example lockdep output:

======================================================
WARNING: possible circular locking dependency detected
------------------------------------------------------
kworker/0:1/37 is trying to acquire lock:
 (&b->lock){+.+.}, at: b_lock+0x14/0x30
but task is already holding lock:
 (&a->lock){+.+.}, at: a_lock+0x14/0x30
the existing dependency chain (in reverse order) is:
 -> #1 (&a->lock):
       lock_acquire+0xd4/0x110
       ...
-> #0 (&b->lock):
       ...

Lock classes: lockdep does not track individual lock instances — it tracks lock classes (all locks of the same type, e.g., all struct inode i_lock instances). This lets it validate ordering rules globally from a handful of observations.

Using lockdep annotations in your code:

lockdep_assert_held(&my_lock);    /* assert lock is held here */
lockdep_assert_irqs_disabled();   /* assert IRQs are off */

Building a kernel with lockdep: In make menuconfig, enable Kernel hacking → Lock debugging (spinlocks, mutexes, etc.). Boot the resulting kernel and run your subsystem's tests. Any detected issue will print a full stack trace to dmesg.

/* Correct lock ordering: always acquire lock_A before lock_B.
   lockdep will warn if any code path does B before A. */

static DEFINE_SPINLOCK(lock_A);
static DEFINE_SPINLOCK(lock_B);

void correct_function(void)
{
    spin_lock(&lock_A);   /* always first */
    spin_lock(&lock_B);   /* always second */
    /* ... critical section ... */
    spin_unlock(&lock_B);
    spin_unlock(&lock_A);
}

void buggy_function(void)
{
    spin_lock(&lock_B);   /* WRONG ORDER — lockdep will catch this */
    spin_lock(&lock_A);
    /* ... */
    spin_unlock(&lock_A);
    spin_unlock(&lock_B);
    /* If correct_function and buggy_function run concurrently
       on two CPUs, they will DEADLOCK. lockdep reports this
       the moment buggy_function is first called. */
}

/* Using lockdep assertion to document invariants */
void must_hold_A(void)
{
    lockdep_assert_held(&lock_A); /* BUG() if not held */
    /* ... */
}

Even without SMP concerns, the compiler itself is your enemy when writing concurrent code. Two specific problems:

1. Invented loads (load tearing): The compiler may read a variable multiple times even if you only wrote one load in C, if it needs to spill/reload a register. If another CPU changes the variable between the two reads, you get inconsistent values within a single "read."

2. Store sinking / load floating: The compiler may reorder accesses to different locations freely, as long as single-threaded semantics are preserved. In a concurrent context, this reordering is a bug.

READ_ONCE(x) and WRITE_ONCE(x, v) solve both problems by:

• Emitting exactly one load or store in the generated assembly.
• Acting as a compiler barrier (prevents the compiler from moving other accesses across them).
• Marking the access as volatile-ish in a targeted way (unlike volatile, which is too broad and misleading).

When to use them:

• Shared variables accessed without locks (e.g., the RCU "ready" flag, a stop condition checked in a polling loop).
• Any variable that can be modified by another CPU, interrupt handler, or memory-mapped hardware register — without a full lock/barrier pair.
• In lock-free algorithms where you are intentionally relying on hardware ordering (and providing your own smp_* barriers).

Do not use volatile in kernel code. The kernel style guide explicitly forbids it for synchronization purposes because it is both too weak (no barrier semantics) and too broad (prevents many useful compiler optimizations). Use READ_ONCE/WRITE_ONCE and explicit barriers instead.

/* Thread A sets a flag; Thread B polls it.
   Without READ_ONCE, the compiler may hoist the load out of the loop
   and spin forever even after the flag is set. */

static int stop_flag;  /* shared between CPU 0 and CPU 1 */

/* CPU 0: signal stop */
void request_stop(void)
{
    WRITE_ONCE(stop_flag, 1);  /* single store, compiler barrier */
}

/* CPU 1: worker loop */
void worker(void)
{
    while (!READ_ONCE(stop_flag)) {  /* compiler cannot cache this */
        do_work();
    }
    pr_info("stopped\n");
}

/* BAD version — compiler may transform while(!stop_flag) into:
   if (!stop_flag) while(1) { do_work(); }  <- infinite loop!
   because it "knows" stop_flag cannot change in this thread. */
void bad_worker(void)
{
    while (!stop_flag) {   /* no READ_ONCE — compiler can hoist */
        do_work();
    }
}