1. 12 9月, 2009 5 次提交
  2. 14 8月, 2009 1 次提交
  3. 17 6月, 2009 8 次提交
  4. 10 5月, 2009 1 次提交
    • H
      V4L/DVB (11669): uvc: fix compile warning · 7564f67d
      Hans Verkuil 提交于
      The 2.6.30 kernel generates this warning:
      
      uvc_driver.c:1729: warning: 'ret' may be used uninitialized in this function
      
      I guess some new warning flag must have been turned on since this warning
      didn't appear with older kernels (gcc version 4.3.1). It's also a bogus
      warning, but since this code didn't comply to the coding standard anyway
      I've modified it to 1) remove the warning and 2) conform to the coding
      standard.
      Signed-off-by: NHans Verkuil <hverkuil@xs4all.nl>
      Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
      7564f67d
  5. 30 3月, 2009 4 次提交
  6. 29 1月, 2009 3 次提交
  7. 30 12月, 2008 9 次提交
  8. 13 10月, 2008 1 次提交
  9. 12 10月, 2008 3 次提交
  10. 06 8月, 2008 1 次提交
  11. 27 7月, 2008 1 次提交
  12. 24 7月, 2008 1 次提交
  13. 20 7月, 2008 2 次提交
    • L
      V4L/DVB (8257): uvcvideo: Fix possible AB-BA deadlock with videodev_lock and open_mutex · a9e28585
      Laurent Pinchart 提交于
      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
      <romano@dea.icai.upcomillas.es>.
      Signed-off-by: NRoland Dreier <roland@digitalvampire.org>
      Signed-off-by: NLaurent Pinchart <laurent.pinchart@skynet.be>
      Signed-off-by: NMauro Carvalho Chehab <mchehab@infradead.org>
      a9e28585
    • L