linux-arm-msm.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Rob Clark <robdclark@gmail.com>
To: Stephen Boyd <swboyd@chromium.org>
Cc: Krishna Manikandan <mkrishn@codeaurora.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	dri-devel <dri-devel@lists.freedesktop.org>,
	freedreno <freedreno@lists.freedesktop.org>,
	linux-arm-msm <linux-arm-msm@vger.kernel.org>
Subject: Re: [PATCH] drm/msm/kms: Make a lock_class_key for each crtc mutex
Date: Wed, 3 Feb 2021 14:11:09 -0800	[thread overview]
Message-ID: <CAF6AEGtFpjpYoY_iu8F2z-RMJ=0+tBYo-akKJ1JbgKagBuQWtA@mail.gmail.com> (raw)
In-Reply-To: <161238950899.76967.16385691346035591773@swboyd.mtv.corp.google.com>

On Wed, Feb 3, 2021 at 1:58 PM Stephen Boyd <swboyd@chromium.org> wrote:
>
> Quoting Rob Clark (2021-02-03 09:29:09)
> > On Wed, Feb 3, 2021 at 2:10 AM Daniel Vetter <daniel@ffwll.ch> wrote:
> > >
> > > On Tue, Feb 02, 2021 at 08:51:25AM -0800, Rob Clark wrote:
> > > > On Tue, Feb 2, 2021 at 7:46 AM Daniel Vetter <daniel@ffwll.ch> wrote:
> > > > >
> > > > > On Mon, Jan 25, 2021 at 03:49:01PM -0800, Stephen Boyd wrote:
> > > > > > 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
> > > > > > 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>
> > > > >
> > > > > This smells like throwing more bad after initial bad code ...
> > > > >
> > > > > First a rant: https://blog.ffwll.ch/2020/08/lockdep-false-positives.html
> > >
> > > Some technical on the patch itself: I think you want
> > > mutex_lock_nested(crtc->lock, drm_crtc_index(crtc)), not your own locking
> > > classes hand-rolled. It's defacto the same, but much more obviously
> > > correct since self-documenting.
> >
> > hmm, yeah, that is a bit cleaner.. but this patch is already on
> > msm-next, maybe I'll add a patch on top to change it
>
> How many CRTCs are there? The subclass number tops out at 8, per
> MAX_LOCKDEP_SUBCLASSES so if we have more than that many bits possible
> then it will fail.

conveniently MAX_CRTCS is 8.. realistically I don't *think* you'd ever
see more than 2 or 3

BR,
-R

  reply	other threads:[~2021-02-03 22:09 UTC|newest]

Thread overview: 10+ 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-28 16:39 ` Rob Clark
2021-02-02 15:46 ` Daniel Vetter
2021-02-02 16:51   ` Rob Clark
2021-02-03 10:10     ` Daniel Vetter
2021-02-03 17:29       ` Rob Clark
2021-02-03 21:58         ` Stephen Boyd
2021-02-03 22:11           ` Rob Clark [this message]
2021-02-04 15:17             ` Daniel Vetter
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='CAF6AEGtFpjpYoY_iu8F2z-RMJ=0+tBYo-akKJ1JbgKagBuQWtA@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: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).