On Thu, May 11, 2017 at 12:01:21PM +0200, Thomas Gleixner wrote: > On Thu, 11 May 2017, Mark Rutland wrote: > > On Thu, May 11, 2017 at 10:30:39AM +0200, Thomas Gleixner wrote: > > > On Wed, 10 May 2017, Thomas Gleixner wrote: > > > secondary_start_kernel() > > > check_local_cpu_capabilities() > > > update_cpu_errata_workarounds() > > > update_cpu_capabilities() > > > static_key_enable() > > > __static_key_slow_inc() > > > jump_label_lock() > > > mutex_lock(&jump_label_mutex); > > > > > > How is that supposed to work? > > > > > > That call path is the low level CPU bringup, running in the context of the > > > idle task of that CPU with interrupts and preemption disabled. Taking a > > > mutex in that context, even if in that case the mutex is uncontended, is a > > > NONO.
> > As an aside, do we have anything that should detect the broken mutex > > usage? I've been testing kernels with LOCKDEP, PROVE_LOCKING, > > DEBUG_ATOMIC_SLEEP, and friends, and nothing has complained so far. > > Peter and myself were wondering about that already. No idea why that > doesn't yell at you. AFAICT, this happens early enough that system_state is SYSTEM_BOOTING. In ___might_sleep(), we see this and bail out without a splat. Thanks, Mark.