设备驱动启动阶段可否使用mutex？咨询mutex可用时机

Great question—this is a super common gotcha when digging into early kernel init code, so let's break it down clearly.

启动阶段绝对不能使用Mutex #

Short answer: No, you can't use mutexes during early kernel initialization when core subsystems aren't fully set up. Here's why:

• Mutexes rely on the kernel's process scheduler to handle blocking: When you call mutex_lock(), if the mutex is held, the current thread will sleep until it's released. But during early init, the scheduler hasn't been initialized yet—there's no way to put a thread to sleep or switch between tasks. This will immediately trigger a kernel panic.
• Mutexes depend on other core infrastructure: Things like the slab allocator (for dynamic mutex initialization via mutex_init()), wait queues, and proper task state management are all still being set up in the early boot phase. Even statically defined mutexes (using DEFINE_MUTEX()) won't work because the underlying mechanisms needed to enforce mutual exclusion aren't ready.

Mutex可以安全投入使用的时机 #

Mutexes become usable once the kernel has finished initializing its core subsystems, specifically:

• After the process scheduler is fully initialized: On most Linux-based systems, this happens after sched_init() completes in start_kernel(). At this point, the kernel can handle task switching and thread blocking safely.
• Once core memory management is online: The slab allocator (used for allocating mutex structures and related objects) needs to be ready. For static mutexes, this is less critical, but the runtime support for mutex operations still requires memory management to be functional.
• When the kernel enters multi-tasking mode: After the initial kernel thread is set up and the system can handle concurrent execution, mutexes are safe to use. This is typically right before the first user-space process (init/systemd) is spawned.

As a general rule of thumb: If you're writing code that runs before start_kernel() completes its core initialization steps (like arch-specific boot code, early hardware setup), stick to non-blocking primitives.

早期初始化阶段的同步替代方案 #

Instead of mutexes, use spinlocks for synchronization during early boot. Spinlocks work by busy-waiting (looping) until the lock is released, which doesn't require the scheduler or blocking support. Just remember to disable interrupts when using spinlocks in early init (since interrupts might not be properly handled yet) with spin_lock_irqsave() and spin_lock_irqrestore().

内容的提问来源于stack exchange，提问作者Manh Tuong Hoang