user/sven/linux.git/include/media, branch v3.18.131

media: v4l: event: Prevent freeing event subscriptions while accessed

2018-10-13T07:09:28Z

commit ad608fbcf166fec809e402d548761768f602702c upstream. The event subscriptions are added to the subscribed event list while holding a spinlock, but that lock is subsequently released while still accessing the subscription object. This makes it possible to unsubscribe the event --- and freeing the subscription object's memory --- while the subscription object is simultaneously accessed. Prevent this by adding a mutex to serialise the event subscription and unsubscription. This also gives a guarantee to the callback ops that the add op has returned before the del op is called. This change also results in making the elems field less special: subscriptions are only added to the event list once they are fully initialised. Signed-off-by: Sakari Ailus Reviewed-by: Hans Verkuil Reviewed-by: Laurent Pinchart Cc: stable@vger.kernel.org # for 4.14 and up Fixes: c3b5b0241f62 ("V4L/DVB: V4L: Events: Add backend") Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman

Merge branch 'patchwork' into v4l_for_linus

2014-10-09T17:00:54Z

* patchwork: (544 commits) [media] ir-hix5hd2: fix build on c6x arch [media] pt3: fix DTV FE I2C driver load error paths Revert "[media] media: em28xx - remove reset_resume interface" [media] exynos4-is: fix some warnings when compiling on arm64 [media] usb drivers: use %zu instead of %zd [media] pci drivers: use %zu instead of %zd [media] dvb-frontends: use %zu instead of %zd [media] s5p-mfc: Fix several printk warnings [media] s5p_mfc_opr: Fix warnings [media] ti-vpe: Fix typecast [media] s3c-camif: fix dma_addr_t printks [media] s5p_mfc_opr_v6: get rid of warnings when compiled with 64 bits [media] s5p_mfc_opr_v5: Fix lots of warnings on x86_64 [media] em28xx: Fix identation [media] drxd: remove a dead code [media] saa7146: remove return after BUG() [media] cx88: remove return after BUG() [media] cx88: fix cards table CodingStyle [media] radio-sf16fmr2: declare some structs as static [media] radio-sf16fmi: declare pnp_attached as static ... Conflicts: Documentation/DocBook/media/v4l/compat.xml

[media] rc: add dvbsky rc keymap macro

2014-09-23T19:13:49Z

This RC will be used by DVBSky driver, added on the next patch. Signed-off-by: Nibble Max Signed-off-by: Mauro Carvalho Chehab

[media] v4l: videobuf2: Fix typos in comments

2014-09-23T19:13:40Z

The buffer flags are incorrectly referred to as V4L2_BUF_FLAGS_* instead of V4L2_BUF_FLAG_* in comments. Fix it. Signed-off-by: Laurent Pinchart Acked-by: Marek Szyprowski Acked-by: Sakari Ailus Signed-off-by: Mauro Carvalho Chehab

[media] vb2: fix VBI/poll regression

2014-09-21T23:57:30Z

The recent conversion of saa7134 to vb2 unconvered a poll() bug that broke the teletext applications alevt and mtt. These applications expect that calling poll() without having called VIDIOC_STREAMON will cause poll() to return POLLERR. That did not happen in vb2. This patch fixes that behavior. It also fixes what should happen when poll() is called when STREAMON is called but no buffers have been queued. In that case poll() will also return POLLERR, but only for capture queues since output queues will always return POLLOUT anyway in that situation. This brings the vb2 behavior in line with the old videobuf behavior. Signed-off-by: Hans Verkuil Acked-by: Laurent Pinchart Signed-off-by: Mauro Carvalho Chehab

[media] videobuf2-core.h: fix comment

2014-09-21T23:45:23Z

The comment for start_streaming that tells the developer with which vb2 state buffers should be returned to vb2 gave the wrong state. Very confusing. Signed-off-by: Hans Verkuil Acked-by: Laurent Pinchart Signed-off-by: Mauro Carvalho Chehab

[media] media: videobuf2-core.h: add a helper to get status of start_streaming()

2014-09-21T23:15:39Z

this patch adds a helper to get the status if start_streaming() was called successfully. Signed-off-by: Lad, Prabhakar Cc: Pawel Osciak Cc: Marek Szyprowski Cc: Kyungmin Park Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab

[media] dm644x_ccdc: use unsigned long for fpc_table_addr

2014-08-26T21:52:03Z

The fpc_table_addr is used as an unsigned integer that stores an address. At the Kernel, the proper type for such integers is unsigned long. This generates lots of warnings when compiling on 64 bits. Signed-off-by: Mauro Carvalho Chehab

[media] videobuf2: fix lockdep warning

2014-08-21T20:25:31Z

The following lockdep warning has been there ever since commit a517cca6b24fc54ac209e44118ec8962051662e3 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: [] vb2_fop_mmap+0x33/0x90 [videobuf2_core] [ 403.117974] [ 403.117974] but task is already holding lock: [ 403.117976] (&mm->mmap_sem){++++++}, at: [] 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] [] validate_chain.isra.39+0x5fc/0x9a0 [ 403.118006] [] __lock_acquire+0x4d3/0xd30 [ 403.118010] [] lock_acquire+0xa7/0x160 [ 403.118014] [] might_fault+0x7c/0xb0 [ 403.118018] [] video_usercopy+0x425/0x610 [videodev] [ 403.118028] [] video_ioctl2+0x15/0x20 [videodev] [ 403.118034] [] v4l2_ioctl+0x184/0x1a0 [videodev] [ 403.118040] [] do_vfs_ioctl+0x2f0/0x4f0 [ 403.118307] [] SyS_ioctl+0x81/0xa0 [ 403.118311] [] system_call_fastpath+0x16/0x1b [ 403.118319] [ 403.118319] -> #0 (&dev->mutex#3){+.+.+.}: [ 403.118324] [] check_prevs_add+0x746/0x9f0 [ 403.118329] [] validate_chain.isra.39+0x5fc/0x9a0 [ 403.118333] [] __lock_acquire+0x4d3/0xd30 [ 403.118336] [] lock_acquire+0xa7/0x160 [ 403.118340] [] mutex_lock_interruptible_nested+0x64/0x640 [ 403.118344] [] vb2_fop_mmap+0x33/0x90 [videobuf2_core] [ 403.118349] [] v4l2_mmap+0x62/0xa0 [videodev] [ 403.118354] [] mmap_region+0x3d0/0x5d0 [ 403.118359] [] do_mmap_pgoff+0x31d/0x400 [ 403.118363] [] vm_mmap_pgoff+0x90/0xc0 [ 403.118366] [] SyS_mmap_pgoff+0x1df/0x2a0 [ 403.118369] [] SyS_mmap+0x22/0x30 [ 403.118376] [] 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: [] 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] [] dump_stack+0x4e/0x7a [ 403.118445] [] print_circular_bug+0x1d5/0x2a0 [ 403.118449] [] check_prevs_add+0x746/0x9f0 [ 403.118455] [] ? find_vmap_area+0x42/0x70 [ 403.118459] [] validate_chain.isra.39+0x5fc/0x9a0 [ 403.118463] [] __lock_acquire+0x4d3/0xd30 [ 403.118468] [] lock_acquire+0xa7/0x160 [ 403.118472] [] ? vb2_fop_mmap+0x33/0x90 [videobuf2_core] [ 403.118476] [] ? vb2_fop_mmap+0x33/0x90 [videobuf2_core] [ 403.118480] [] mutex_lock_interruptible_nested+0x64/0x640 [ 403.118484] [] ? vb2_fop_mmap+0x33/0x90 [videobuf2_core] [ 403.118488] [] ? vb2_fop_mmap+0x33/0x90 [videobuf2_core] [ 403.118493] [] ? mark_held_locks+0x75/0xa0 [ 403.118497] [] vb2_fop_mmap+0x33/0x90 [videobuf2_core] [ 403.118502] [] v4l2_mmap+0x62/0xa0 [videodev] [ 403.118506] [] mmap_region+0x3d0/0x5d0 [ 403.118510] [] do_mmap_pgoff+0x31d/0x400 [ 403.118513] [] vm_mmap_pgoff+0x90/0xc0 [ 403.118517] [] SyS_mmap_pgoff+0x1df/0x2a0 [ 403.118521] [] SyS_mmap+0x22/0x30 [ 403.118525] [] 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: Hans Verkuil Acked-by: Laurent Pinchart Acked-by: Marek Szyprowski Signed-off-by: Mauro Carvalho Chehab

[media] omap3isp: ccdc: Add basic support for interlaced video

2014-08-21T20:25:14Z

When the CCDC input is interlaced enable the alternate field order on the CCDC output video node. The field signal polarity is specified through platform data. Signed-off-by: Laurent Pinchart Tested-by: Enrico Butera Acked-by: Sakari Ailus Signed-off-by: Mauro Carvalho Chehab