From: Rob Clark <robdclark@gmail.com> To: Stephen Boyd <swboyd@chromium.org> Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>, linux-arm-msm <linux-arm-msm@vger.kernel.org>, freedreno <freedreno@lists.freedesktop.org>, dri-devel <dri-devel@lists.freedesktop.org>, Krishna Manikandan <mkrishn@codeaurora.org> Subject: Re: [PATCH] drm/msm/kms: Make a lock_class_key for each crtc mutex Date: Thu, 28 Jan 2021 08:39:12 -0800 [thread overview] Message-ID: <CAF6AEGu1WHbzV5pazm2w7t7XzSeHJgTvip4FHdpqTm+SnLEpLQ@mail.gmail.com> (raw) In-Reply-To: <20210125234901.2730699-1-swboyd@chromium.org> On Mon, Jan 25, 2021 at 3:49 PM Stephen Boyd <swboyd@chromium.org> wrote: > > Lockdep complains about an AA deadlock when rebooting the device. > > ============================================ > 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 on static key for every nit, s/on/one/ ? BR, -R > 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> > --- > 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 d8151a89e163..4735251a394d 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; > > > base-commit: 19c329f6808995b142b3966301f217c831e7cf31 > -- > https://chromeos.dev >
WARNING: multiple messages have this Message-ID (diff)
From: Rob Clark <robdclark@gmail.com> To: Stephen Boyd <swboyd@chromium.org> Cc: linux-arm-msm <linux-arm-msm@vger.kernel.org>, freedreno <freedreno@lists.freedesktop.org>, Linux Kernel Mailing List <linux-kernel@vger.kernel.org>, dri-devel <dri-devel@lists.freedesktop.org>, Krishna Manikandan <mkrishn@codeaurora.org> Subject: Re: [PATCH] drm/msm/kms: Make a lock_class_key for each crtc mutex Date: Thu, 28 Jan 2021 08:39:12 -0800 [thread overview] Message-ID: <CAF6AEGu1WHbzV5pazm2w7t7XzSeHJgTvip4FHdpqTm+SnLEpLQ@mail.gmail.com> (raw) In-Reply-To: <20210125234901.2730699-1-swboyd@chromium.org> On Mon, Jan 25, 2021 at 3:49 PM Stephen Boyd <swboyd@chromium.org> wrote: > > Lockdep complains about an AA deadlock when rebooting the device. > > ============================================ > 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 on static key for every nit, s/on/one/ ? BR, -R > 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> > --- > 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 d8151a89e163..4735251a394d 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; > > > base-commit: 19c329f6808995b142b3966301f217c831e7cf31 > -- > https://chromeos.dev > _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
next prev parent reply other threads:[~2021-01-28 16:38 UTC|newest] Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-01-25 23:49 [PATCH] drm/msm/kms: Make a lock_class_key for each crtc mutex Stephen Boyd 2021-01-25 23:49 ` Stephen Boyd 2021-01-28 16:39 ` Rob Clark [this message] 2021-01-28 16:39 ` Rob Clark 2021-02-02 15:46 ` Daniel Vetter 2021-02-02 15:46 ` Daniel Vetter 2021-02-02 16:51 ` Rob Clark 2021-02-02 16:51 ` Rob Clark 2021-02-03 10:10 ` Daniel Vetter 2021-02-03 10:10 ` Daniel Vetter 2021-02-03 17:29 ` Rob Clark 2021-02-03 17:29 ` Rob Clark 2021-02-03 21:58 ` Stephen Boyd 2021-02-03 21:58 ` Stephen Boyd 2021-02-03 22:11 ` Rob Clark 2021-02-03 22:11 ` Rob Clark 2021-02-04 15:17 ` Daniel Vetter 2021-02-04 15:17 ` Daniel Vetter 2021-01-26 2:01 Stephen Boyd 2021-01-26 2:01 ` Stephen Boyd
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=CAF6AEGu1WHbzV5pazm2w7t7XzSeHJgTvip4FHdpqTm+SnLEpLQ@mail.gmail.com \ --to=robdclark@gmail.com \ --cc=dri-devel@lists.freedesktop.org \ --cc=freedreno@lists.freedesktop.org \ --cc=linux-arm-msm@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=mkrishn@codeaurora.org \ --cc=swboyd@chromium.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.