lkml.org 
[lkml]   [2017]   [May]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCHv3 0/2] arm64: fix hotplug rwsem boot fallout
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.

\
 
 \ /
  Last update: 2017-05-11 14:56    [W:0.149 / U:0.504 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site