lkml.org 
[lkml]   [2021]   [Mar]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    Patch in this message
    /
    From
    Subject[PATCH 5.11 498/775] drm/msm/kms: Make a lock_class_key for each crtc mutex
    Date
    From: Stephen Boyd <swboyd@chromium.org>

    [ Upstream commit 6ec9351809612fa1c0256fb3e39b49b6100e2983 ]

    Lockdep complains about an AA deadlock when rebooting the device.

    base-commit: 19c329f6808995b142b3966301f217c831e7cf31

    ============================================
    WARNING: possible recursive locking detected
    5.4.91 #1 Not tainted
    --------------------------------------------
    reboot/5213 is trying to acquire lock:
    ffffff80d13391b0 (&kms->commit_lock[i]){+.+.}, at: lock_crtcs+0x60/0xa4

    but task is already holding lock:
    ffffff80d1339110 (&kms->commit_lock[i]){+.+.}, at: lock_crtcs+0x60/0xa4

    other info that might help us debug this:
    Possible unsafe locking scenario:

    CPU0
    ----
    lock(&kms->commit_lock[i]);
    lock(&kms->commit_lock[i]);

    *** DEADLOCK ***

    May be due to missing lock nesting notation

    6 locks held by reboot/5213:
    __arm64_sys_reboot+0x148/0x2a0
    device_shutdown+0x10c/0x2c4
    drm_atomic_helper_shutdown+0x48/0xfc
    modeset_lock+0x120/0x24c
    lock_crtcs+0x60/0xa4

    stack backtrace:
    CPU: 4 PID: 5213 Comm: reboot Not tainted 5.4.91 #1
    Hardware name: Google Pompom (rev1) with LTE (DT)
    Call trace:
    dump_backtrace+0x0/0x1dc
    show_stack+0x24/0x30
    dump_stack+0xfc/0x1a8
    __lock_acquire+0xcd0/0x22b8
    lock_acquire+0x1ec/0x240
    __mutex_lock_common+0xe0/0xc84
    mutex_lock_nested+0x48/0x58
    lock_crtcs+0x60/0xa4
    msm_atomic_commit_tail+0x348/0x570
    commit_tail+0xdc/0x178
    drm_atomic_helper_commit+0x160/0x168
    drm_atomic_commit+0x68/0x80

    This is because lockdep thinks all the locks taken in lock_crtcs() are
    the same lock, when they actually aren't. That's because we call
    mutex_init() in msm_kms_init() and that assigns one static key for every
    lock initialized in this loop. Let's allocate a dynamic number of
    lock_class_keys and assign them to each lock so that lockdep can figure
    out an AA deadlock isn't possible here.

    Fixes: b3d91800d9ac ("drm/msm: Fix race condition in msm driver with async layer updates")
    Cc: Krishna Manikandan <mkrishn@codeaurora.org>
    Signed-off-by: Stephen Boyd <swboyd@chromium.org>
    Signed-off-by: Rob Clark <robdclark@chromium.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>
    ---
    drivers/gpu/drm/msm/msm_kms.h | 8 ++++++--
    1 file changed, 6 insertions(+), 2 deletions(-)

    diff --git a/drivers/gpu/drm/msm/msm_kms.h b/drivers/gpu/drm/msm/msm_kms.h
    index d8151a89e1631..4735251a394d8 100644
    --- a/drivers/gpu/drm/msm/msm_kms.h
    +++ b/drivers/gpu/drm/msm/msm_kms.h
    @@ -157,6 +157,7 @@ struct msm_kms {
    * from the crtc's pending_timer close to end of the frame:
    */
    struct mutex commit_lock[MAX_CRTCS];
    + struct lock_class_key commit_lock_keys[MAX_CRTCS];
    unsigned pending_crtc_mask;
    struct msm_pending_timer pending_timers[MAX_CRTCS];
    };
    @@ -166,8 +167,11 @@ static inline int msm_kms_init(struct msm_kms *kms,
    {
    unsigned i, ret;

    - for (i = 0; i < ARRAY_SIZE(kms->commit_lock); i++)
    - mutex_init(&kms->commit_lock[i]);
    + for (i = 0; i < ARRAY_SIZE(kms->commit_lock); i++) {
    + lockdep_register_key(&kms->commit_lock_keys[i]);
    + __mutex_init(&kms->commit_lock[i], "&kms->commit_lock[i]",
    + &kms->commit_lock_keys[i]);
    + }

    kms->funcs = funcs;

    --
    2.27.0


    \
     
     \ /
      Last update: 2021-03-02 05:40    [W:4.040 / U:1.272 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site