From: Laurent Pinchart Date: Fri, 11 Jul 2008 22:32:15 +0000 (-0300) Subject: V4L/DVB (8257): uvcvideo: Fix possible AB-BA deadlock with videodev_lock and open_mutex X-Git-Tag: v2.6.27-rc1~966^2~116 X-Git-Url: http://git.openpandora.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=a9e285856112e5e721b6a341d15437a164128b30;p=pandora-kernel.git V4L/DVB (8257): uvcvideo: Fix possible AB-BA deadlock with videodev_lock and open_mutex The uvcvideo driver's uvc_v4l2_open() method is called from videodev's video_open() function, which means it is called with the videodev_lock mutex held. uvc_v4l2_open() then takes uvc_driver.open_mutex to check dev->state and avoid racing against a device disconnect, which means that open_mutex must nest inside videodev_lock. However uvc_disconnect() takes the open_mutex around setting dev->state and also around putting its device reference. However, if uvc_disconnect() ends up dropping the last reference, it will call uvc_delete(), which calls into the videodev code to unregister its device, and this will end up taking videodev_lock. This opens a (unlikely in practice) window for an AB-BA deadlock and also causes a lockdep warning because of the lock misordering. Fortunately there is no apparent reason to hold open_mutex when doing kref_put() in uvc_disconnect(): if uvc_v4l2_open() runs before the state is set to UVC_DEV_DISCONNECTED, then it will take another reference to the device and kref_put() won't call uvc_delete; if uvc_v4l2_open() runs after the state is set, it will run before uvc_delete(), see the state, and return immediately -- uvc_delete() does uvc_unregister_video() (and hence video_unregister_device(), which is synchronized with videodev_lock) as its first thing, so there is no risk of use-after-free in uvc_v4l2_open(). Bug diagnosed based on a lockdep warning reported by Romano Giannetti . Signed-off-by: Roland Dreier Signed-off-by: Laurent Pinchart Signed-off-by: Mauro Carvalho Chehab --- Reading git-diff-tree failed