• S
    clocksource: cadence_ttc: Fix mutex taken inside interrupt context · c1dcc927
    Soren Brinkmann 提交于
    When the kernel is compiled with:
    CONFIG_HIGH_RES_TIMERS=no
    CONFIG_HZ_PERIODIC=yes
    CONFIG_DEBUG_ATOMIC_SLEEP=yes
    
    The following WARN appears:
    
    WARNING: CPU: 1 PID: 0 at linux/kernel/mutex.c:856 mutex_trylock+0x70/0x1fc()
    DEBUG_LOCKS_WARN_ON(in_interrupt())
    Modules linked in:
    CPU: 1 PID: 0 Comm: swapper/1 Not tainted 3.12.0-xilinx-dirty #93
    [<c0014a78>] (unwind_backtrace+0x0/0x11c) from [<c0011b6c>] (show_stack+0x10/0x14)
    [<c0011b6c>] (show_stack+0x10/0x14) from [<c039120c>] (dump_stack+0x7c/0xc0)
    [<c039120c>] (dump_stack+0x7c/0xc0) from [<c001fda4>] (warn_slowpath_common+0x60/0x84)
    [<c001fda4>] (warn_slowpath_common+0x60/0x84) from [<c001fe48>] (warn_slowpath_fmt+0x2c/0x3c)
    [<c001fe48>] (warn_slowpath_fmt+0x2c/0x3c) from [<c0392658>] (mutex_trylock+0x70/0x1fc)
    [<c0392658>] (mutex_trylock+0x70/0x1fc) from [<c02dfc08>] (clk_prepare_lock+0xc/0xe4)
    [<c02dfc08>] (clk_prepare_lock+0xc/0xe4) from [<c02e099c>] (clk_get_rate+0xc/0x44)
    [<c02e099c>] (clk_get_rate+0xc/0x44) from [<c02d0394>] (ttc_set_mode+0x34/0x78)
    [<c02d0394>] (ttc_set_mode+0x34/0x78) from [<c005f794>] (clockevents_set_mode+0x28/0x5c)
    [<c005f794>] (clockevents_set_mode+0x28/0x5c) from [<c00607fc>] (tick_broadcast_on_off+0x190/0x1c0)
    [<c00607fc>] (tick_broadcast_on_off+0x190/0x1c0) from [<c005f168>] (clockevents_notify+0x58/0x1ac)
    [<c005f168>] (clockevents_notify+0x58/0x1ac) from [<c02b99dc>] (cpuidle_setup_broadcast_timer+0x20/0x24)
    [<c02b99dc>] (cpuidle_setup_broadcast_timer+0x20/0x24) from [<c006cd04>] (generic_smp_call_function_single_interrupt+0)
    [<c006cd04>] (generic_smp_call_function_single_interrupt+0xe0/0x130) from [<c00138c8>] (handle_IPI+0x88/0x118)
    [<c00138c8>] (handle_IPI+0x88/0x118) from [<c0008504>] (gic_handle_irq+0x58/0x60)
    [<c0008504>] (gic_handle_irq+0x58/0x60) from [<c0012644>] (__irq_svc+0x44/0x78)
    Exception stack(0xef099fa0 to 0xef099fe8)
    9fa0: 00000001 ef092100 00000000 ef092100 ef098000 00000015 c0399f2c c0579d74
    9fc0: 0000406a 413fc090 00000000 00000000 00000000 ef099fe8 c00666ec c000f46c
    9fe0: 20000113 ffffffff
    [<c0012644>] (__irq_svc+0x44/0x78) from [<c000f46c>] (arch_cpu_idle+0x34/0x3c)
    [<c000f46c>] (arch_cpu_idle+0x34/0x3c) from [<c0053980>] (cpu_startup_entry+0xa8/0x10c)
    [<c0053980>] (cpu_startup_entry+0xa8/0x10c) from [<000085a4>] (0x85a4)
    
    We are in an interrupt context (IPI) and we are calling clk_get_rate in the
    set_mode function which in turn ends up by getting a mutex... Even if that
    does not hang, it is a potential kernel deadlock.
    
    It is not allowed to call clk_get_rate() from interrupt context. To
    avoid such calls the timer input frequency is stored in the driver's
    data struct which makes it accessible to the driver in any context.
    
    [dlezcano] completed the changelog with the WARN trace and added a more
    detailed description. Tested on zync zc702.
    Acked-by: NDaniel Lezcano <daniel.lezcano@linaro.org>
    Tested-by: NDaniel Lezcano <daniel.lezcano@linaro.org>
    Signed-off-by: NSoren Brinkmann <soren.brinkmann@xilinx.com>
    Signed-off-by: NDaniel Lezcano <daniel.lezcano@linaro.org>
    c1dcc927
cadence_ttc_timer.c 12.9 KB