« Previous Lecture  |  Next Lecture »

The Scenario That Produces the Report

Lockdep prints a self-deadlock warning whenever a single thread of execution tries to acquire a lock it is already holding — without going through an unlock first. This most commonly happens indirectly: your code takes a lock, and then somewhere deeper in the call chain it calls a helper function that, unknown to you, tries to take that exact same lock again. On kernel builds without lockdep this simply hangs forever with no explanation. On a lockdep-enabled kernel, you get a full diagnostic report the moment the second acquire is attempted — before the deadlock actually happens.

Anatomy of the Warning — Line by Line

Read it top to bottom as a story: lockdep first tells you what the code was about to do (“is trying to acquire”), then tells you what the code had already done earlier in the same call path (“already holding”). Everything else in the report exists to help you connect those two moments.

The Lock Identity Hash — How You Know It’s the Same Lock

Each of the two lock lines begins with a long hexadecimal number. That number is a hash lockdep computes to uniquely identify that specific lock instance in memory. If the hash on the “trying to acquire” line matches the hash on the “already holding” line, you have proof — not a guess — that both acquire attempts refer to the exact same lock object. This is the single most useful fact in the whole report: it immediately rules out “maybe these are two different locks that just look similar,” which is normally the hardest thing to confirm by manual code reading alone.

Understanding the Lock State Notation

Next to the lock class name you will see a short bracketed code made up of symbols such as plus signs and dots. This is lockdep’s compact record of the interrupt state the lock has previously been acquired under — for example, whether it has ever been taken with hardware interrupts enabled, with interrupts disabled, or from softirq context. Lockdep tracks this because a lock that is safe when only ever taken from process context can become unsafe the moment it is also taken from an interrupt handler, opening the door to a completely different class of deadlock that we cover later in this chapter. For a self-deadlock report specifically, this notation is secondary — the two matching hashes and the “already holding” line are what matter first.

Finding the Real Bug in Your Own Code

Once you know two acquire attempts share a lock, the fix is almost always the same shape: somewhere in your call chain, a helper function takes a lock that the caller already holds. Here is a minimal, original example of the pattern — a device driver context structure protected by a spinlock, and a status-formatting helper that mistakenly re-takes it:

struct ep_dev_ctx {
    spinlock_t lock;
    int status_code;
    char status_text[32];
};

/* BUG: this helper takes the same lock its only caller
 * already holds, producing a textbook self-deadlock. */
static void ep_format_status(struct ep_dev_ctx *ctx, char *out, size_t len)
{
    unsigned long flags;

    spin_lock_irqsave(&ctx->lock, flags);
    snprintf(out, len, "code=%d text=%s",
              ctx->status_code, ctx->status_text);
    spin_unlock_irqrestore(&ctx->lock, flags);
}

static void ep_dump_status(struct ep_dev_ctx *ctx)
{
    unsigned long flags;
    char buf[64];

    spin_lock_irqsave(&ctx->lock, flags);   /* lock taken here */
    ctx->status_code = 1;

    ep_format_status(ctx, buf, sizeof(buf)); /* tries to take it again! */

    spin_unlock_irqrestore(&ctx->lock, flags);
}

The Fix: Unlock, Call, Relock

The correct fix is not to remove locking from either function — both genuinely need to protect their access to ctx. The fix is to release the lock immediately before calling the helper, and take it again right after, so the two critical sections never overlap:

static void ep_dump_status_fixed(struct ep_dev_ctx *ctx)
{
    unsigned long flags;
    char buf[64];

    spin_lock_irqsave(&ctx->lock, flags);
    ctx->status_code = 1;
    spin_unlock_irqrestore(&ctx->lock, flags);   /* release first */

    ep_format_status(ctx, buf, sizeof(buf));      /* helper locks internally */

    spin_lock_irqsave(&ctx->lock, flags);         /* reacquire */
    /* continue with any remaining protected work */
    spin_unlock_irqrestore(&ctx->lock, flags);
}

This is exactly the pattern lockdep is nudging you toward whenever it reports recursive locking: shrink each critical section so that a lock is never held across a call into code that might take it again. On kernel 6.x you can immediately confirm the fix by reloading the module and checking that the “possible recursive locking detected” warning no longer appears in dmesg.

Looking Ahead: When Two Locks Are Involved

A single-lock self-deadlock is the simplest case lockdep detects. In the next lecture we move to a more common real-world scenario: two separate locks acquired by two different threads in opposite order, known as an AB-BA deadlock. Lockdep catches this too, and the report format you just learned to read is the exact same format it uses there — just with a second lock’s identity hash added to the picture.

« Previous Lecture  |  Next Lecture »