1. 20 Oct, 2015 3 commits
  2. 05 Oct, 2015 1 commit
  3. 01 Oct, 2015 3 commits
  4. 22 Aug, 2015 1 commit
  5. 17 Jul, 2015 1 commit
    • Sakari Ailus's avatar
      [media] vb2: Only requeue buffers immediately once streaming is started · 6d058c56
      Sakari Ailus authored
      Buffers can be returned back to videobuf2 in driver's streamon handler. In
      this case vb2_buffer_done() with buffer state VB2_BUF_STATE_QUEUED will
      cause the driver's buf_queue vb2 operation to be called, queueing the same
      buffer again only to be returned to videobuf2 using vb2_buffer_done() and so
      on.
      
      Add a new buffer state VB2_BUF_STATE_REQUEUEING which, when used as the
      state argument to vb2_buffer_done(), will result in buffers queued to the
      driver. Using VB2_BUF_STATE_QUEUED will leave the buffer to videobuf2, as it
      was before "[media] vb2: allow requeuing buffers while streaming".
      
      Fixes: ce0eff01 ("[media] vb2: allow requeuing buffers while streaming")
      
      [mchehab@osg.samsung.com: fix warning: enumeration value 'VB2_BUF_STATE_REQUEUEING' not handled in switch]
      Signed-off-by: default avatarSakari Ailus <sakari.ailus@linux.intel.com>
      Acked-by: default avatarHans Verkuil <hans.verkuil@cisco.com>
      Cc: stable@vger.kernel.org # for v4.1
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@osg.samsung.com>
      6d058c56
  6. 12 May, 2015 1 commit
  7. 10 Apr, 2015 2 commits
  8. 25 Nov, 2014 3 commits
  9. 23 Sep, 2014 1 commit
  10. 21 Sep, 2014 3 commits
  11. 21 Aug, 2014 1 commit
    • Hans Verkuil's avatar
      [media] videobuf2: fix lockdep warning · f035eb4e
      Hans Verkuil authored
      The following lockdep warning has been there ever since commit a517cca6
      one year ago:
      
      [  403.117947] ======================================================
      [  403.117949] [ INFO: possible circular locking dependency detected ]
      [  403.117953] 3.16.0-rc6-test-media #961 Not tainted
      [  403.117954] -------------------------------------------------------
      [  403.117956] v4l2-ctl/15377 is trying to acquire lock:
      [  403.117959]  (&dev->mutex#3){+.+.+.}, at: [<ffffffffa005a6c3>] vb2_fop_mmap+0x33/0x90 [videobuf2_core]
      [  403.117974]
      [  403.117974] but task is already holding lock:
      [  403.117976]  (&mm->mmap_sem){++++++}, at: [<ffffffff8118291f>] vm_mmap_pgoff+0x6f/0xc0
      [  403.117987]
      [  403.117987] which lock already depends on the new lock.
      [  403.117987]
      [  403.117990]
      [  403.117990] the existing dependency chain (in reverse order) is:
      [  403.117992]
      [  403.117992] -> #1 (&mm->mmap_sem){++++++}:
      [  403.117997]        [<ffffffff810d733c>] validate_chain.isra.39+0x5fc/0x9a0
      [  403.118006]        [<ffffffff810d8bc3>] __lock_acquire+0x4d3/0xd30
      [  403.118010]        [<ffffffff810d9da7>] lock_acquire+0xa7/0x160
      [  403.118014]        [<ffffffff8118c9ec>] might_fault+0x7c/0xb0
      [  403.118018]        [<ffffffffa0028a25>] video_usercopy+0x425/0x610 [videodev]
      [  403.118028]        [<ffffffffa0028c25>] video_ioctl2+0x15/0x20 [videodev]
      [  403.118034]        [<ffffffffa0022764>] v4l2_ioctl+0x184/0x1a0 [videodev]
      [  403.118040]        [<ffffffff811d77d0>] do_vfs_ioctl+0x2f0/0x4f0
      [  403.118307]        [<ffffffff811d7a51>] SyS_ioctl+0x81/0xa0
      [  403.118311]        [<ffffffff8199dc69>] system_call_fastpath+0x16/0x1b
      [  403.118319]
      [  403.118319] -> #0 (&dev->mutex#3){+.+.+.}:
      [  403.118324]        [<ffffffff810d6a96>] check_prevs_add+0x746/0x9f0
      [  403.118329]        [<ffffffff810d733c>] validate_chain.isra.39+0x5fc/0x9a0
      [  403.118333]        [<ffffffff810d8bc3>] __lock_acquire+0x4d3/0xd30
      [  403.118336]        [<ffffffff810d9da7>] lock_acquire+0xa7/0x160
      [  403.118340]        [<ffffffff81999664>] mutex_lock_interruptible_nested+0x64/0x640
      [  403.118344]        [<ffffffffa005a6c3>] vb2_fop_mmap+0x33/0x90 [videobuf2_core]
      [  403.118349]        [<ffffffffa0022122>] v4l2_mmap+0x62/0xa0 [videodev]
      [  403.118354]        [<ffffffff81197270>] mmap_region+0x3d0/0x5d0
      [  403.118359]        [<ffffffff8119778d>] do_mmap_pgoff+0x31d/0x400
      [  403.118363]        [<ffffffff81182940>] vm_mmap_pgoff+0x90/0xc0
      [  403.118366]        [<ffffffff81195cef>] SyS_mmap_pgoff+0x1df/0x2a0
      [  403.118369]        [<ffffffff810085c2>] SyS_mmap+0x22/0x30
      [  403.118376]        [<ffffffff8199dc69>] system_call_fastpath+0x16/0x1b
      [  403.118381]
      [  403.118381] other info that might help us debug this:
      [  403.118381]
      [  403.118383]  Possible unsafe locking scenario:
      [  403.118383]
      [  403.118385]        CPU0                    CPU1
      [  403.118387]        ----                    ----
      [  403.118388]   lock(&mm->mmap_sem);
      [  403.118391]                                lock(&dev->mutex#3);
      [  403.118394]                                lock(&mm->mmap_sem);
      [  403.118397]   lock(&dev->mutex#3);
      [  403.118400]
      [  403.118400]  *** DEADLOCK ***
      [  403.118400]
      [  403.118403] 1 lock held by v4l2-ctl/15377:
      [  403.118405]  #0:  (&mm->mmap_sem){++++++}, at: [<ffffffff8118291f>] vm_mmap_pgoff+0x6f/0xc0
      [  403.118411]
      [  403.118411] stack backtrace:
      [  403.118415] CPU: 0 PID: 15377 Comm: v4l2-ctl Not tainted 3.16.0-rc6-test-media #961
      [  403.118418] Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 07/31/2013
      [  403.118420]  ffffffff82a6c9d0 ffff8800af37fb00 ffffffff819916a2 ffffffff82a6c9d0
      [  403.118425]  ffff8800af37fb40 ffffffff810d5715 ffff8802308e4200 0000000000000000
      [  403.118429]  ffff8802308e4a48 ffff8802308e4a48 ffff8802308e4200 0000000000000001
      [  403.118433] Call Trace:
      [  403.118441]  [<ffffffff819916a2>] dump_stack+0x4e/0x7a
      [  403.118445]  [<ffffffff810d5715>] print_circular_bug+0x1d5/0x2a0
      [  403.118449]  [<ffffffff810d6a96>] check_prevs_add+0x746/0x9f0
      [  403.118455]  [<ffffffff8119c172>] ? find_vmap_area+0x42/0x70
      [  403.118459]  [<ffffffff810d733c>] validate_chain.isra.39+0x5fc/0x9a0
      [  403.118463]  [<ffffffff810d8bc3>] __lock_acquire+0x4d3/0xd30
      [  403.118468]  [<ffffffff810d9da7>] lock_acquire+0xa7/0x160
      [  403.118472]  [<ffffffffa005a6c3>] ? vb2_fop_mmap+0x33/0x90 [videobuf2_core]
      [  403.118476]  [<ffffffffa005a6c3>] ? vb2_fop_mmap+0x33/0x90 [videobuf2_core]
      [  403.118480]  [<ffffffff81999664>] mutex_lock_interruptible_nested+0x64/0x640
      [  403.118484]  [<ffffffffa005a6c3>] ? vb2_fop_mmap+0x33/0x90 [videobuf2_core]
      [  403.118488]  [<ffffffffa005a6c3>] ? vb2_fop_mmap+0x33/0x90 [videobuf2_core]
      [  403.118493]  [<ffffffff810d8055>] ? mark_held_locks+0x75/0xa0
      [  403.118497]  [<ffffffffa005a6c3>] vb2_fop_mmap+0x33/0x90 [videobuf2_core]
      [  403.118502]  [<ffffffffa0022122>] v4l2_mmap+0x62/0xa0 [videodev]
      [  403.118506]  [<ffffffff81197270>] mmap_region+0x3d0/0x5d0
      [  403.118510]  [<ffffffff8119778d>] do_mmap_pgoff+0x31d/0x400
      [  403.118513]  [<ffffffff81182940>] vm_mmap_pgoff+0x90/0xc0
      [  403.118517]  [<ffffffff81195cef>] SyS_mmap_pgoff+0x1df/0x2a0
      [  403.118521]  [<ffffffff810085c2>] SyS_mmap+0x22/0x30
      [  403.118525]  [<ffffffff8199dc69>] system_call_fastpath+0x16/0x1b
      
      The reason is that vb2_fop_mmap and vb2_fop_get_unmapped_area take the core lock
      while they are called with the mmap_sem semaphore held. But elsewhere in the code
      the core lock is taken first but calls to copy_to/from_user() can take the mmap_sem
      semaphore as well, potentially causing a classical A-B/B-A deadlock.
      
      However, the mmap/get_unmapped_area calls really shouldn't take the core lock
      at all. So what would happen if they don't take the core lock anymore?
      
      There are two situations that need to be taken into account: calling mmap while
      new buffers are being added and calling mmap while buffers are being deleted.
      
      The first case works almost fine without a lock: in all cases mmap relies on
      correctly filled-in q->num_buffers/q->num_planes values and those are only
      updated by reqbufs and create_buffers *after* any new buffers have been
      initialized completely. Except in one case: if an error occurred while allocating
      the buffers it will increase num_buffers and rely on __vb2_queue_free to
      decrease it again. So there is a short period where the buffer information
      may be wrong.
      
      The second case definitely does pose a problem: buffers may be in the process
      of being deleted, without the internal structure being updated.
      
      In order to fix this a new mutex is added to vb2_queue that is taken when
      buffers are allocated or deleted, and in vb2_mmap. That way vb2_mmap won't
      get stale buffer data. Note that this is a problem only for MEMORY_MMAP, so
      even though __qbuf_userptr and __qbuf_dmabuf also mess around with buffers
      (mem_priv in particular), this doesn't clash with vb2_mmap or
      vb2_get_unmapped_area since those are MMAP specific.
      
      As an additional bonus the hack in __buf_prepare, the USERPTR case, can be
      removed as well since mmap() no longer takes the core lock.
      
      All in all a much cleaner solution.
      Signed-off-by: default avatarHans Verkuil <hans.verkuil@cisco.com>
      Acked-by: default avatarLaurent Pinchart <laurent.pinchart@ideasonboard.com>
      Acked-by: default avatarMarek Szyprowski <m.szyprowski@samsung.com>
      Signed-off-by: default avatarMauro Carvalho Chehab <m.chehab@samsung.com>
      f035eb4e
  12. 25 Jul, 2014 1 commit
  13. 17 Jul, 2014 1 commit
    • Laurent Pinchart's avatar
      [media] v4l: vb2: Add fatal error condition flag · 4bb7267d
      Laurent Pinchart authored
      When a fatal error occurs that render the device unusable, the only
      options for a driver to signal the error condition to userspace is to
      set the V4L2_BUF_FLAG_ERROR flag when dequeuing buffers and to return an
      error from the buffer prepare handler when queuing buffers.
      
      The buffer error flag indicates a transient error and can't be used by
      applications to detect fatal errors. Returning an error from vb2_qbuf()
      is thus the only real indication that a fatal error occurred. However,
      this is difficult to handle for multithreaded applications that requeue
      buffers from a thread other than the control thread. In particular the
      poll() call in the control thread will not notify userspace of the
      error.
      
      This patch adds an explicit mechanism to report fatal errors to
      userspace. Drivers can call the vb2_queue_error() function to signal a
      fatal error. From this moment on, buffer preparation will return -EIO to
      userspace, and vb2_poll() will set the POLLERR flag and return
      immediately. The error flag is cleared when cancelling the queue, either
      at stream off time (through vb2_streamoff) or when releasing the queue
      with vb2_queue_release().
      Signed-off-by: default avatarLaurent Pinchart <laurent.pinchart@ideasonboard.com>
      Acked-by: default avatarHans Verkuil <hans.verkuil@cisco.com>
      Signed-off-by: default avatarMauro Carvalho Chehab <m.chehab@samsung.com>
      4bb7267d
  14. 25 May, 2014 1 commit
  15. 23 Apr, 2014 1 commit
  16. 16 Apr, 2014 2 commits
  17. 11 Mar, 2014 6 commits
  18. 05 Mar, 2014 2 commits
  19. 07 Jan, 2014 2 commits
  20. 09 Dec, 2013 2 commits
    • Philipp Zabel's avatar
      [media] videobuf2: Add support for file access mode flags for DMABUF exporting · c1b96a23
      Philipp Zabel authored
      Currently it is not possible for userspace to map a DMABUF exported buffer
      with write permissions. This patch allows to also pass O_RDONLY/O_RDWR when
      exporting the buffer, so that userspace may map it with write permissions.
      Signed-off-by: default avatarPhilipp Zabel <p.zabel@pengutronix.de>
      Signed-off-by: default avatarSylwester Nawrocki <s.nawrocki@samsung.com>
      Signed-off-by: default avatarMauro Carvalho Chehab <m.chehab@samsung.com>
      c1b96a23
    • Ricardo Ribalda's avatar
      [media] videobuf2: Add missing lock held on vb2_fop_release · 1380f575
      Ricardo Ribalda authored
      vb2_fop_release does not hold the lock although it is modifying the
      queue->owner field.
      This could lead to race conditions on the vb2_perform_io function
      when multiple applications are accessing the video device via
      read/write API:
      [ 308.297741] BUG: unable to handle kernel NULL pointer dereference at
      0000000000000260
      [ 308.297759] IP: [<ffffffffa07a9fd2>] vb2_perform_fileio+0x372/0x610
      [videobuf2_core]
      [ 308.297794] PGD 159719067 PUD 158119067 PMD 0
      [ 308.297812] Oops: 0000 #1 SMP
      [ 308.297826] Modules linked in: qt5023_video videobuf2_dma_sg
      qtec_xform videobuf2_vmalloc videobuf2_memops videobuf2_core
      qtec_white qtec_mem gpio_xilinx qtec_cmosis qtec_pcie fglrx(PO)
      spi_xilinx spi_bitbang qt5023
      [ 308.297888] CPU: 1 PID: 2189 Comm: java Tainted: P O 3.11.0-qtec-standard #1
      [ 308.297919] Hardware name: QTechnology QT5022/QT5022, BIOS
      PM_2.1.0.309 X64 05/23/2013
      [ 308.297952] task: ffff8801564e1690 ti: ffff88014dc02000 task.ti:
      ffff88014dc02000
      [ 308.297962] RIP: 0010:[<ffffffffa07a9fd2>] [<ffffffffa07a9fd2>]
      vb2_perform_fileio+0x372/0x610 [videobuf2_core]
      [ 308.297985] RSP: 0018:ffff88014dc03df8 EFLAGS: 00010202
      [ 308.297995] RAX: 0000000000000000 RBX: ffff880158a23000 RCX: dead000000100100
      [ 308.298003] RDX: 0000000000000000 RSI: dead000000200200 RDI: 0000000000000000
      [ 308.298012] RBP: ffff88014dc03e58 R08: 0000000000000000 R09: 0000000000000001
      [ 308.298020] R10: ffffea00051e8380 R11: ffff88014dc03fd8 R12: ffff880158a23070
      [ 308.298029] R13: ffff8801549040b8 R14: 0000000000198000 R15: 0000000001887e60
      [ 308.298040] FS: 00007f65130d5700(0000) GS:ffff88015ed00000(0000)
      knlGS:0000000000000000
      [ 308.298049] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [ 308.298057] CR2: 0000000000000260 CR3: 0000000159630000 CR4: 00000000000007e0
      [ 308.298064] Stack:
      [ 308.298071] ffff880156416c00 0000000000198000 0000000000000000
      ffff880100000001
      [ 308.298087] ffff88014dc03f50 00000000810a79ca 0002000000000001
      ffff880154904718
      [ 308.298101] ffff880156416c00 0000000000198000 ffff880154904338
      ffff88014dc03f50
      [ 308.298116] Call Trace:
      [ 308.298143] [<ffffffffa07aa3c4>] vb2_read+0x14/0x20 [videobuf2_core]
      [ 308.298198] [<ffffffffa07aa494>] vb2_fop_read+0xc4/0x120 [videobuf2_core]
      [ 308.298252] [<ffffffff8154ee9e>] v4l2_read+0x7e/0xc0
      [ 308.298296] [<ffffffff8116e639>] vfs_read+0xa9/0x160
      [ 308.298312] [<ffffffff8116e882>] SyS_read+0x52/0xb0
      [ 308.298328] [<ffffffff81784179>] tracesys+0xd0/0xd5
      [ 308.298335] Code: e5 d6 ff ff 83 3d be 24 00 00 04 89 c2 4c 8b 45 b0
      44 8b 4d b8 0f 8f 20 02 00 00 85 d2 75 32 83 83 78 03 00 00 01 4b 8b
      44 c5 48 <8b> 88 60 02 00 00 85 c9 0f 84 b0 00 00 00 8b 40 58 89 c2 41
      89
      [ 308.298487] RIP [<ffffffffa07a9fd2>] vb2_perform_fileio+0x372/0x610
      [videobuf2_core]
      [ 308.298507] RSP <ffff88014dc03df8>
      [ 308.298514] CR2: 0000000000000260
      [ 308.298526] ---[ end trace e8f01717c96d1e41 ]---
      Signed-off-by: default avatarRicardo Ribalda <ricardo.ribalda@gmail.com>
      Acked-by: default avatarHans Verkuil <hans.verkuil@cisco.com>
      Acked-by: default avatarSylwester Nawrocki <s.nawrocki@samsung.com>
      Signed-off-by: default avatarHans Verkuil <hans.verkuil@cisco.com>
      Signed-off-by: default avatarMauro Carvalho Chehab <m.chehab@samsung.com>
      1380f575
  21. 29 Nov, 2013 1 commit
  22. 26 Sep, 2013 1 commit