summaryrefslogtreecommitdiff
path: root/drivers/gpu/drm/drm_framebuffer.c
diff options
context:
space:
mode:
authorThomas Hellstrom <thellstrom@vmware.com>2018-03-21 10:18:38 +0100
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>2018-03-28 18:24:40 +0200
commit19246741a6dfabb59ddb43ec1af3d0d7cc9aa64a (patch)
tree3895ed48ad412c6827f1f087e156b51517f9c075 /drivers/gpu/drm/drm_framebuffer.c
parent4be50a9fe670525e19d7173f9441302a57df6ac3 (diff)
drm/vmwgfx: Fix a destoy-while-held mutex problem.
commit 73a88250b70954a8f27c2444e1c2411bba3c29d9 upstream. When validating legacy surfaces, the backup bo might be destroyed at surface validate time. However, the kms resource validation code may have the bo reserved, so we will destroy a locked mutex. While there shouldn't be any other users of that mutex when it is destroyed, it causes a lock leak and thus throws a lockdep error. Fix this by having the kms resource validation code hold a reference to the bo while we have it reserved. We do this by introducing a validation context which might come in handy when the kms code is extended to validate multiple resources or buffers. Cc: <stable@vger.kernel.org> Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com> Reviewed-by: Brian Paul <brianp@vmware.com> Reviewed-by: Sinclair Yeh <syeh@vmware.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Diffstat (limited to 'drivers/gpu/drm/drm_framebuffer.c')
0 files changed, 0 insertions, 0 deletions