On Thu, May 11, 2017 at 12:01:21PM +0200, Thomas Gleixner wrote:

On Thu, 11 May 2017, Mark Rutland wrote:

quoted

On Thu, May 11, 2017 at 10:30:39AM +0200, Thomas Gleixner wrote:

quoted

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.

quoted

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.