On Tue, May 16, 2017 at 03:18:05PM +0100, Mark Rutland wrote: > Currently, cpus_set_cap() calls static_branch_enable_cpuslocked(), which > must take the jump_label mutex. > > We call cpus_set_cap() in the secondary bringup path, from the idle > thread where interrupts are disabled. Taking a mutex in this path "is a > NONO" regardless of whether it's contended, and something we must avoid. > We didn't spot this until recently, as ___might_sleep() won't warn for > this case until all CPUs have been brought up. > > This patch avoids taking the mutex in the secondary bringup path. The > poking of static keys is deferred until enable_cpu_capabilities(), which > runs in a suitable context on the boot CPU. To account for the static > keys being set later, cpus_have_const_cap() is updated to use another > static key to check whether the const cap keys have been initialised, > falling back to the caps bitmap until this is the case. > > This means that users of cpus_have_const_cap() gain should only gain a > single additional NOP in the fast path once the const caps are > initialised, but should always see the current cap value. > > The hyp code should never dereference the caps array, since the caps are > initialized before we run the module initcall to initialise hyp. A check > is added to the hyp init code to document this requirement. > > This change will sidestep a number of issues when the upcoming hotplug > locking rework is merged. > > Signed-off-by: Mark Rutland <[email protected]> > Reviewed-by: Marc Zyniger <[email protected]> > Reviewed-by: Suzuki Poulose <[email protected]> > Acked-by: Will Deacon <[email protected]> > Cc: Catalin Marinas <[email protected]> > Cc: Christoffer Dall <[email protected]> > Cc: Peter Zijlstra <[email protected]> > Cc: Sebastian Sewior <[email protected]> > Cc: Thomas Gleixner <[email protected]> > --- > arch/arm64/include/asm/cpufeature.h | 12 ++++++++++-- > arch/arm64/include/asm/kvm_host.h | 8 ++++++-- > arch/arm64/kernel/cpufeature.c | 23 +++++++++++++++++++++-- > 3 files changed, 37 insertions(+), 6 deletions(-) > > Catalin, can you take this as a fix for v4.12?
I queued it for 4.12-rc2. Thanks. -- Catalin
