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.