1. 24 8月, 2016 3 次提交
  2. 09 7月, 2016 4 次提交
  3. 16 6月, 2016 1 次提交
  4. 25 4月, 2016 1 次提交
  5. 14 4月, 2016 1 次提交
  6. 27 2月, 2016 1 次提交
  7. 04 2月, 2016 2 次提交
    • M
      [media] vb2-core: call threadio->fnc() if !VB2_BUF_STATE_ERROR · 1f2c4501
      Mauro Carvalho Chehab 提交于
      changeset 70433a15 ("media: videobuf2: Refactor vb2_fileio_data
      and vb2_thread") broke videobuf2-dvb.
      
      The root cause is that, instead of calling threadio->fnc() for
      all types of events except for VB2_BUF_STATE_ERROR, it was calling
      it only for VB2_BUF_STATE_DONE.
      
      With that, the DVB thread were never called.
      
      Cc: stable@vger.kernel.org # Kernel >= 4.3
      Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>
      1f2c4501
    • H
      [media] vb2: fix nasty vb2_thread regression · fac710e4
      Hans Verkuil 提交于
      The vb2_thread implementation was made generic and was moved from
      videobuf2-v4l2.c to videobuf2-core.c in commit af3bac1a. Unfortunately
      that clearly was never tested since it broke read() causing NULL address
      references.
      
      The root cause was confused handling of vb2_buffer vs v4l2_buffer (the pb
      pointer in various core functions).
      
      The v4l2_buffer no longer exists after moving the code into the core and
      it is no longer needed. However, the vb2_thread code passed a pointer to
      a vb2_buffer to the core functions were a v4l2_buffer pointer was expected
      and vb2_thread expected that the vb2_buffer fields would be filled in
      correctly.
      
      This is obviously wrong since v4l2_buffer != vb2_buffer. Note that the
      pb pointer is a void pointer, so no type-checking took place.
      
      This patch fixes this problem:
      
      1) allow pb to be NULL for vb2_core_(d)qbuf. The vb2_thread code will use
         a NULL pointer here since they don't care about v4l2_buffer anyway.
      2) let vb2_core_dqbuf pass back the index of the received buffer. This is
         all vb2_thread needs: this index is the index into the q->bufs array
         and vb2_thread just gets the vb2_buffer from there.
      3) the fileio->b pointer (that originally contained a v4l2_buffer) is
         removed altogether since it is no longer needed.
      
      Tested with vivid and the cobalt driver.
      
      Cc: stable@vger.kernel.org # Kernel >= 4.3
      Signed-off-by: NHans Verkuil <hans.verkuil@cisco.com>
      Reported-by: NMatthias Schwarzott <zzam@gentoo.org>
      Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>
      fac710e4
  8. 01 2月, 2016 1 次提交
  9. 19 12月, 2015 6 次提交
  10. 18 12月, 2015 4 次提交
  11. 21 10月, 2015 3 次提交
  12. 01 10月, 2015 2 次提交
  13. 17 8月, 2015 1 次提交
    • J
      [media] vb2: Push mmap_sem down to memops · 0f6e2825
      Jan Kara 提交于
      Currently vb2 core acquires mmap_sem just around call to
      __qbuf_userptr(). However since commit f035eb4e (videobuf2: fix
      lockdep warning) it isn't necessary to acquire it so early as we no
      longer have to drop queue mutex before acquiring mmap_sem. So push
      acquisition of mmap_sem down into .get_userptr memop so that the
      semaphore is acquired for a shorter time and it is clearer what it is
      needed for.
      
      Note that we also need mmap_sem in .put_userptr memop since that ends up
      calling vb2_put_vma() which calls vma->vm_ops->close() which should be
      called with mmap_sem held. However we didn't hold mmap_sem in some code
      paths anyway (e.g. when called via vb2_ioctl_reqbufs() ->
      __vb2_queue_free() -> vb2_dma_sg_put_userptr()) and getting mmap_sem in
      put_userptr() introduces a lock inversion with queue->mmap_lock in the
      above mentioned call path.
      
      Luckily this whole locking mess will get resolved once we convert
      videobuf2 core to the new mm helper which avoids the need for mmap_sem
      in .put_userptr memop altogether.
      Signed-off-by: NJan Kara <jack@suse.cz>
      Signed-off-by: NHans Verkuil <hans.verkuil@cisco.com>
      Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>
      0f6e2825
  14. 10 8月, 2015 1 次提交
  15. 17 7月, 2015 2 次提交
    • P
      [media] videobuf2: add trace events · 2091f518
      Philipp Zabel 提交于
      Add videobuf2 specific vb2_qbuf and vb2_dqbuf trace events that mirror the
      v4l2_qbuf and v4l2_dqbuf trace events, only they include additional
      information about queue fill state and are emitted right before the buffer
      is enqueued in the driver or userspace is woken up. This allows to make
      sense of the timeline of trace events in combination with others that might
      be triggered by __enqueue_in_driver.
      
      Also two new trace events vb2_buf_queue and vb2_buf_done are added,
      allowing to trace the handover between videobuf2 framework and driver.
      Signed-off-by: NPhilipp Zabel <p.zabel@pengutronix.de>
      Signed-off-by: NHans Verkuil <hans.verkuil@cisco.com>
      Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>
      2091f518
    • S
      [media] vb2: Only requeue buffers immediately once streaming is started · 6d058c56
      Sakari Ailus 提交于
      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: NSakari Ailus <sakari.ailus@linux.intel.com>
      Acked-by: NHans Verkuil <hans.verkuil@cisco.com>
      Cc: stable@vger.kernel.org # for v4.1
      Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>
      6d058c56
  16. 22 6月, 2015 1 次提交
  17. 19 6月, 2015 1 次提交
    • H
      [media] Revert "[media] vb2: Push mmap_sem down to memops" · 511a1b8a
      Hans Verkuil 提交于
      This reverts commit 48b25a3a.
      
      That commit caused two regressions. The first is a BUG:
      
      Jun 14 18:42:15 test-media kernel: [  115.972299] BUG: unable to handle kernel NULL pointer dereference at 0000000000000100
      Jun 14 18:42:15 test-media kernel: [  115.972307] IP: [<ffffffff810d5cd0>] __lock_acquire+0x2f0/0x2070
      Jun 14 18:42:15 test-media kernel: [  115.972316] PGD 0
      Jun 14 18:42:15 test-media kernel: [  115.972318] Oops: 0000 [#1] PREEMPT SMP
      Jun 14 18:42:15 test-media kernel: [  115.972321] Modules linked in: vivid v4l2_dv_timings videobuf2_vmalloc videobuf2_memops videobuf2_core v4l2_common videodev media vmw_balloon vmw_vmci acpi_cpufreq processor button
      Jun 14 18:42:15 test-media kernel: [  115.972333] CPU: 0 PID: 1542 Comm: v4l2-ctl Not tainted 4.1.0-rc3-test-media #1190
      Jun 14 18:42:15 test-media kernel: [  115.972336] Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 05/20/2014
      Jun 14 18:42:15 test-media kernel: [  115.972337] task: ffff880220ce4200 ti: ffff88021d16c000 task.ti: ffff88021d16c000
      Jun 14 18:42:15 test-media kernel: [  115.972339] RIP: 0010:[<ffffffff810d5cd0>]  [<ffffffff810d5cd0>] __lock_acquire+0x2f0/0x2070
      Jun 14 18:42:15 test-media kernel: [  115.972342] RSP: 0018:ffff88021d16f9b8  EFLAGS: 00010002
      Jun 14 18:42:15 test-media kernel: [  115.972343] RAX: 0000000000000046 RBX: 0000000000000292 RCX: 0000000000000001
      Jun 14 18:42:15 test-media kernel: [  115.972345] RDX: 0000000000000000 RSI: 0000000000000001 RDI: 0000000000000100
      Jun 14 18:42:15 test-media kernel: [  115.972346] RBP: ffff88021d16fa88 R08: 0000000000000001 R09: 0000000000000000
      Jun 14 18:42:15 test-media kernel: [  115.972347] R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000001
      Jun 14 18:42:15 test-media kernel: [  115.972348] R13: ffff880220ce4200 R14: 0000000000000100 R15: 0000000000000000
      Jun 14 18:42:15 test-media kernel: [  115.972350] FS:  00007f2441e7f740(0000) GS:ffff880236e00000(0000) knlGS:0000000000000000
      Jun 14 18:42:15 test-media kernel: [  115.972351] CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
      Jun 14 18:42:15 test-media kernel: [  115.972353] CR2: 0000000000000100 CR3: 0000000001e0b000 CR4: 00000000001406f0
      Jun 14 18:42:15 test-media kernel: [  115.972424] Stack:
      Jun 14 18:42:15 test-media kernel: [  115.972427]  ffff88021d16fa98 ffffffff810d6543 0000000000000006 0000000000000246
      Jun 14 18:42:15 test-media kernel: [  115.972431]  ffff88021d16fa08 ffffffff810d532d ffff880220ce4a78 ffff880200000000
      Jun 14 18:42:15 test-media kernel: [  115.972433]  ffff880200000001 0000000000000000 0000000000000001 000000000093a4a0
      Jun 14 18:42:15 test-media kernel: [  115.972436] Call Trace:
      Jun 14 18:42:15 test-media kernel: [  115.972440]  [<ffffffff810d6543>] ? __lock_acquire+0xb63/0x2070
      Jun 14 18:42:15 test-media kernel: [  115.972443]  [<ffffffff810d532d>] ? mark_held_locks+0x6d/0xa0
      Jun 14 18:42:15 test-media kernel: [  115.972445]  [<ffffffff810d37a8>] ? __lock_is_held+0x58/0x80
      Jun 14 18:42:15 test-media kernel: [  115.972447]  [<ffffffff810d852c>] lock_acquire+0x6c/0xa0
      Jun 14 18:42:15 test-media kernel: [  115.972452]  [<ffffffffa039f1f6>] ? vb2_vmalloc_put_userptr+0x36/0x110 [videobuf2_vmalloc]
      Jun 14 18:42:15 test-media kernel: [  115.972458]  [<ffffffff819b1a92>] down_read+0x42/0x60
      Jun 14 18:42:15 test-media kernel: [  115.972460]  [<ffffffffa039f1f6>] ? vb2_vmalloc_put_userptr+0x36/0x110 [videobuf2_vmalloc]
      Jun 14 18:42:15 test-media kernel: [  115.972463]  [<ffffffff819af1b1>] ? mutex_lock_nested+0x2b1/0x560
      Jun 14 18:42:15 test-media kernel: [  115.972467]  [<ffffffffa038fdc5>] ? vb2_queue_release+0x25/0x40 [videobuf2_core]
      Jun 14 18:42:15 test-media kernel: [  115.972469]  [<ffffffffa039f1f6>] vb2_vmalloc_put_userptr+0x36/0x110 [videobuf2_vmalloc]
      Jun 14 18:42:15 test-media kernel: [  115.972472]  [<ffffffffa038b626>] __vb2_queue_free+0x146/0x5e0 [videobuf2_core]
      Jun 14 18:42:15 test-media kernel: [  115.972475]  [<ffffffffa038fdd3>] vb2_queue_release+0x33/0x40 [videobuf2_core]
      Jun 14 18:42:15 test-media kernel: [  115.972478]  [<ffffffffa038fe75>] _vb2_fop_release+0x95/0xb0 [videobuf2_core]
      Jun 14 18:42:15 test-media kernel: [  115.972481]  [<ffffffffa038feb9>] vb2_fop_release+0x29/0x50 [videobuf2_core]
      Jun 14 18:42:15 test-media kernel: [  115.972485]  [<ffffffffa03ad372>] vivid_fop_release+0x92/0x230 [vivid]
      Jun 14 18:42:15 test-media kernel: [  115.972491]  [<ffffffffa0358460>] v4l2_release+0x30/0x80 [videodev]
      Jun 14 18:42:15 test-media kernel: [  115.972496]  [<ffffffff811a51d5>] __fput+0xe5/0x200
      Jun 14 18:42:15 test-media kernel: [  115.972498]  [<ffffffff811a5339>] ____fput+0x9/0x10
      Jun 14 18:42:15 test-media kernel: [  115.972501]  [<ffffffff810a9fa4>] task_work_run+0xc4/0xf0
      Jun 14 18:42:15 test-media kernel: [  115.972504]  [<ffffffff8108c670>] do_exit+0x3a0/0xaf0
      Jun 14 18:42:15 test-media kernel: [  115.972507]  [<ffffffff819b3a9b>] ? _raw_spin_unlock_irq+0x2b/0x60
      Jun 14 18:42:15 test-media kernel: [  115.972509]  [<ffffffff8108e0ff>] do_group_exit+0x4f/0xe0
      Jun 14 18:42:15 test-media kernel: [  115.972511]  [<ffffffff8109a170>] get_signal+0x200/0x8c0
      Jun 14 18:42:15 test-media kernel: [  115.972514]  [<ffffffff819b14b5>] ? __mutex_unlock_slowpath+0xf5/0x240
      Jun 14 18:42:15 test-media kernel: [  115.972518]  [<ffffffff81002593>] do_signal+0x23/0x820
      Jun 14 18:42:15 test-media kernel: [  115.972521]  [<ffffffff819b1609>] ? mutex_unlock+0x9/0x10
      Jun 14 18:42:15 test-media kernel: [  115.972524]  [<ffffffffa0358648>] ? v4l2_ioctl+0x78/0xf0 [videodev]
      Jun 14 18:42:15 test-media kernel: [  115.972526]  [<ffffffff819b4653>] ? int_very_careful+0x5/0x46
      Jun 14 18:42:15 test-media kernel: [  115.972529]  [<ffffffff810d54bd>] ? trace_hardirqs_on_caller+0x15d/0x200
      Jun 14 18:42:15 test-media kernel: [  115.972531]  [<ffffffff81002de0>] do_notify_resume+0x50/0x60
      Jun 14 18:42:15 test-media kernel: [  115.972533]  [<ffffffff819b46a6>] int_signal+0x12/0x17
      Jun 14 18:42:15 test-media kernel: [  115.972534] Code: ca 81 31 c0 e8 7a e2 8c 00 e8 aa 1d 8d 00 0f 1f 44 00 00 31 db 48 81 c4 a8 00 00 00 89 d8 5b 41 5c 41 5d 41 5e 41 5f 5d c3 66 90 <49> 81 3e 40 4e 02 82 b8 00 00 00 00 44 0f 44 e0 41 83 ff 01 0f
      Jun 14 18:42:15 test-media kernel: [  115.972567] RIP  [<ffffffff810d5cd0>] __lock_acquire+0x2f0/0x2070
      Jun 14 18:42:15 test-media kernel: [  115.972569]  RSP <ffff88021d16f9b8>
      Jun 14 18:42:15 test-media kernel: [  115.972570] CR2: 0000000000000100
      Jun 14 18:42:15 test-media kernel: [  115.972573] ---[ end trace 25595c2b8560cb57 ]---
      Jun 14 18:42:15 test-media kernel: [  115.972575] Fixing recursive fault but reboot is needed!
      
      This can be reproduced by loading the vivid driver and running:
      
      v4l2-ctl --stream-user
      
      and pressing Ctrl-C. You may have to try a few times, but in my experience this BUG
      is triggered quite quickly.
      
      The second is a possible deadlock:
      
      Jun 14 18:44:07 test-media kernel: [   49.376650] ======================================================
      Jun 14 18:44:07 test-media kernel: [   49.376651] [ INFO: possible circular locking dependency detected ]
      Jun 14 18:44:07 test-media kernel: [   49.376653] 4.1.0-rc3-test-media #1190 Not tainted
      Jun 14 18:44:07 test-media kernel: [   49.376654] -------------------------------------------------------
      Jun 14 18:44:07 test-media kernel: [   49.376655] v4l2-compliance/1468 is trying to acquire lock:
      Jun 14 18:44:07 test-media kernel: [   49.376657]  (&mm->mmap_sem){++++++}, at: [<ffffffffa03a81f6>] vb2_vmalloc_put_userptr+0x36/0x110 [videobuf2_vmalloc]
      Jun 14 18:44:07 test-media kernel: [   49.376665]
      Jun 14 18:44:07 test-media kernel: [   49.376665] but task is already holding lock:
      Jun 14 18:44:07 test-media kernel: [   49.376666]  (&q->mmap_lock){+.+...}, at: [<ffffffffa0398dc5>] vb2_queue_release+0x25/0x40 [videobuf2_core]
      Jun 14 18:44:07 test-media kernel: [   49.376670]
      Jun 14 18:44:07 test-media kernel: [   49.376670] which lock already depends on the new lock.
      Jun 14 18:44:07 test-media kernel: [   49.376670]
      Jun 14 18:44:07 test-media kernel: [   49.376671]
      Jun 14 18:44:07 test-media kernel: [   49.376671] the existing dependency chain (in reverse order) is:
      Jun 14 18:44:07 test-media kernel: [   49.376672]
      Jun 14 18:44:07 test-media kernel: [   49.376672] -> #1 (&q->mmap_lock){+.+...}:
      Jun 14 18:44:07 test-media kernel: [   49.376675]        [<ffffffff810d852c>] lock_acquire+0x6c/0xa0
      Jun 14 18:44:07 test-media kernel: [   49.376682]        [<ffffffff819aef5e>] mutex_lock_nested+0x5e/0x560
      Jun 14 18:44:07 test-media kernel: [   49.376689]        [<ffffffffa03934a2>] vb2_mmap+0x232/0x350 [videobuf2_core]
      Jun 14 18:44:07 test-media kernel: [   49.376691]        [<ffffffffa0395a60>] vb2_fop_mmap+0x20/0x30 [videobuf2_core]
      Jun 14 18:44:07 test-media kernel: [   49.376694]        [<ffffffffa0361102>] v4l2_mmap+0x52/0x90 [videodev]
      Jun 14 18:44:07 test-media kernel: [   49.376698]        [<ffffffff81177e33>] mmap_region+0x3b3/0x5e0
      Jun 14 18:44:07 test-media kernel: [   49.376701]        [<ffffffff81178377>] do_mmap_pgoff+0x317/0x400
      Jun 14 18:44:07 test-media kernel: [   49.376703]        [<ffffffff81165320>] vm_mmap_pgoff+0x90/0xc0
      Jun 14 18:44:07 test-media kernel: [   49.376708]        [<ffffffff81176867>] SyS_mmap_pgoff+0x1d7/0x280
      Jun 14 18:44:07 test-media kernel: [   49.376709]        [<ffffffff81007f8d>] SyS_mmap+0x1d/0x20
      Jun 14 18:44:07 test-media kernel: [   49.376714]        [<ffffffff819b44ae>] system_call_fastpath+0x12/0x76
      Jun 14 18:44:07 test-media kernel: [   49.376716]
      Jun 14 18:44:07 test-media kernel: [   49.376716] -> #0 (&mm->mmap_sem){++++++}:
      Jun 14 18:44:07 test-media kernel: [   49.376718]        [<ffffffff810d79b3>] __lock_acquire+0x1fd3/0x2070
      Jun 14 18:44:07 test-media kernel: [   49.376720]        [<ffffffff810d852c>] lock_acquire+0x6c/0xa0
      Jun 14 18:44:07 test-media kernel: [   49.376721]        [<ffffffff819b1a92>] down_read+0x42/0x60
      Jun 14 18:44:07 test-media kernel: [   49.376723]        [<ffffffffa03a81f6>] vb2_vmalloc_put_userptr+0x36/0x110 [videobuf2_vmalloc]
      Jun 14 18:44:07 test-media kernel: [   49.376725]        [<ffffffffa0394626>] __vb2_queue_free+0x146/0x5e0 [videobuf2_core]
      Jun 14 18:44:07 test-media kernel: [   49.376727]        [<ffffffffa0398dd3>] vb2_queue_release+0x33/0x40 [videobuf2_core]
      Jun 14 18:44:07 test-media kernel: [   49.376729]        [<ffffffffa0398e75>] _vb2_fop_release+0x95/0xb0 [videobuf2_core]
      Jun 14 18:44:07 test-media kernel: [   49.376731]        [<ffffffffa0398eb9>] vb2_fop_release+0x29/0x50 [videobuf2_core]
      Jun 14 18:44:07 test-media kernel: [   49.376733]        [<ffffffffa03b6372>] vivid_fop_release+0x92/0x230 [vivid]
      Jun 14 18:44:07 test-media kernel: [   49.376737]        [<ffffffffa0361460>] v4l2_release+0x30/0x80 [videodev]
      Jun 14 18:44:07 test-media kernel: [   49.376739]        [<ffffffff811a51d5>] __fput+0xe5/0x200
      Jun 14 18:44:07 test-media kernel: [   49.376744]        [<ffffffff811a5339>] ____fput+0x9/0x10
      Jun 14 18:44:07 test-media kernel: [   49.376746]        [<ffffffff810a9fa4>] task_work_run+0xc4/0xf0
      Jun 14 18:44:07 test-media kernel: [   49.376749]        [<ffffffff81002dd1>] do_notify_resume+0x41/0x60
      Jun 14 18:44:07 test-media kernel: [   49.376752]        [<ffffffff819b46a6>] int_signal+0x12/0x17
      Jun 14 18:44:07 test-media kernel: [   49.376754]
      Jun 14 18:44:07 test-media kernel: [   49.376754] other info that might help us debug this:
      Jun 14 18:44:07 test-media kernel: [   49.376754]
      Jun 14 18:44:07 test-media kernel: [   49.376755]  Possible unsafe locking scenario:
      Jun 14 18:44:07 test-media kernel: [   49.376755]
      Jun 14 18:44:07 test-media kernel: [   49.376756]        CPU0                    CPU1
      Jun 14 18:44:07 test-media kernel: [   49.376757]        ----                    ----
      Jun 14 18:44:07 test-media kernel: [   49.376758]   lock(&q->mmap_lock);
      Jun 14 18:44:07 test-media kernel: [   49.376759]                                lock(&mm->mmap_sem);
      Jun 14 18:44:07 test-media kernel: [   49.376760]                                lock(&q->mmap_lock);
      Jun 14 18:44:07 test-media kernel: [   49.376761]   lock(&mm->mmap_sem);
      Jun 14 18:44:07 test-media kernel: [   49.376763]
      Jun 14 18:44:07 test-media kernel: [   49.376763]  *** DEADLOCK ***
      Jun 14 18:44:07 test-media kernel: [   49.376763]
      Jun 14 18:44:07 test-media kernel: [   49.376764] 2 locks held by v4l2-compliance/1468:
      Jun 14 18:44:07 test-media kernel: [   49.376765]  #0:  (&dev->mutex#3){+.+.+.}, at: [<ffffffffa0398e0a>] _vb2_fop_release+0x2a/0xb0 [videobuf2_core]
      Jun 14 18:44:07 test-media kernel: [   49.376770]  #1:  (&q->mmap_lock){+.+...}, at: [<ffffffffa0398dc5>] vb2_queue_release+0x25/0x40 [videobuf2_core]
      Jun 14 18:44:07 test-media kernel: [   49.376773]
      Jun 14 18:44:07 test-media kernel: [   49.376773] stack backtrace:
      Jun 14 18:44:07 test-media kernel: [   49.376776] CPU: 2 PID: 1468 Comm: v4l2-compliance Not tainted 4.1.0-rc3-test-media #1190
      Jun 14 18:44:07 test-media kernel: [   49.376777] Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 05/20/2014
      Jun 14 18:44:07 test-media kernel: [   49.376779]  ffffffff8279e0b0 ffff88021d6f7ba8 ffffffff819a7aac 0000000000000011
      Jun 14 18:44:07 test-media kernel: [   49.376781]  ffffffff8279e0b0 ffff88021d6f7bf8 ffffffff819a3964 ffff88021d6f7bd8
      Jun 14 18:44:07 test-media kernel: [   49.376783]  ffff8800ac8aa100 0000000000000002 ffff8800ac8aa9a0 0000000000000002
      Jun 14 18:44:07 test-media kernel: [   49.376785] Call Trace:
      Jun 14 18:44:07 test-media kernel: [   49.376788]  [<ffffffff819a7aac>] dump_stack+0x4f/0x7b
      Jun 14 18:44:07 test-media kernel: [   49.376792]  [<ffffffff819a3964>] print_circular_bug+0x20f/0x251
      Jun 14 18:44:07 test-media kernel: [   49.376793]  [<ffffffff810d79b3>] __lock_acquire+0x1fd3/0x2070
      Jun 14 18:44:07 test-media kernel: [   49.376795]  [<ffffffff810d6543>] ? __lock_acquire+0xb63/0x2070
      Jun 14 18:44:07 test-media kernel: [   49.376797]  [<ffffffff810d37a8>] ? __lock_is_held+0x58/0x80
      Jun 14 18:44:07 test-media kernel: [   49.376798]  [<ffffffff810d852c>] lock_acquire+0x6c/0xa0
      Jun 14 18:44:07 test-media kernel: [   49.376800]  [<ffffffffa03a81f6>] ? vb2_vmalloc_put_userptr+0x36/0x110 [videobuf2_vmalloc]
      Jun 14 18:44:07 test-media kernel: [   49.376802]  [<ffffffff819b1a92>] down_read+0x42/0x60
      Jun 14 18:44:07 test-media kernel: [   49.376803]  [<ffffffffa03a81f6>] ? vb2_vmalloc_put_userptr+0x36/0x110 [videobuf2_vmalloc]
      Jun 14 18:44:07 test-media kernel: [   49.376805]  [<ffffffff819af1b1>] ? mutex_lock_nested+0x2b1/0x560
      Jun 14 18:44:07 test-media kernel: [   49.376807]  [<ffffffffa0398dc5>] ? vb2_queue_release+0x25/0x40 [videobuf2_core]
      Jun 14 18:44:07 test-media kernel: [   49.376808]  [<ffffffffa03a81f6>] vb2_vmalloc_put_userptr+0x36/0x110 [videobuf2_vmalloc]
      Jun 14 18:44:07 test-media kernel: [   49.376810]  [<ffffffffa0398e0a>] ? _vb2_fop_release+0x2a/0xb0 [videobuf2_core]
      Jun 14 18:44:07 test-media kernel: [   49.376812]  [<ffffffffa0394626>] __vb2_queue_free+0x146/0x5e0 [videobuf2_core]
      Jun 14 18:44:07 test-media kernel: [   49.376814]  [<ffffffffa0398dd3>] vb2_queue_release+0x33/0x40 [videobuf2_core]
      Jun 14 18:44:07 test-media kernel: [   49.376816]  [<ffffffffa0398e75>] _vb2_fop_release+0x95/0xb0 [videobuf2_core]
      Jun 14 18:44:07 test-media kernel: [   49.376818]  [<ffffffffa0398eb9>] vb2_fop_release+0x29/0x50 [videobuf2_core]
      Jun 14 18:44:07 test-media kernel: [   49.376820]  [<ffffffffa03b6372>] vivid_fop_release+0x92/0x230 [vivid]
      Jun 14 18:44:07 test-media kernel: [   49.376822]  [<ffffffffa0361460>] v4l2_release+0x30/0x80 [videodev]
      Jun 14 18:44:07 test-media kernel: [   49.376824]  [<ffffffff811a51d5>] __fput+0xe5/0x200
      Jun 14 18:44:07 test-media kernel: [   49.376825]  [<ffffffff819b4653>] ? int_very_careful+0x5/0x46
      Jun 14 18:44:07 test-media kernel: [   49.376827]  [<ffffffff811a5339>] ____fput+0x9/0x10
      Jun 14 18:44:07 test-media kernel: [   49.376828]  [<ffffffff810a9fa4>] task_work_run+0xc4/0xf0
      Jun 14 18:44:07 test-media kernel: [   49.376830]  [<ffffffff81002dd1>] do_notify_resume+0x41/0x60
      Jun 14 18:44:07 test-media kernel: [   49.376832]  [<ffffffff819b46a6>] int_signal+0x12/0x17
      
      This can be triggered by loading the vivid module with the module option 'no_error_inj=1'
      and running 'v4l2-compliance -s5'. Again, it may take a few attempts to trigger this
      but for me it happens quite quickly.
      
      Without this patch I cannot reproduce these two issues. So reverting is the best
      solution for now.
      Signed-off-by: NHans Verkuil <hans.verkuil@cisco.com>
      Cc: Jan Kara <jack@suse.cz>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>
      511a1b8a
  18. 21 5月, 2015 1 次提交
  19. 12 5月, 2015 1 次提交
  20. 01 5月, 2015 1 次提交
  21. 22 4月, 2015 1 次提交
    • L
      media: remove unused variable that causes a warning · 1d11437f
      Linus Torvalds 提交于
      My 'allmodconfig' build is _almost_ free of warnings, and most of the
      remaining ones are for legacy drivers that just do bad things that I
      can't find it in my black heart to care too much about.  But this one
      was just annoying me:
      
         drivers/media/v4l2-core/videobuf2-core.c:3256:26: warning: unused variable ‘fileio’ [-Wunused-variable]
      
      because commit 0e661006 ("[media] vb2: fix 'UNBALANCED' warnings
      when calling vb2_thread_stop()") removed all users of 'fileio' and
      instead calls "__vb2_cleanup_fileio(q)" to clean up q->fileio.  But the
      now unused 'fileio' variable was left around.
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      1d11437f
  22. 10 4月, 2015 1 次提交