- 26 Aug, 2014 15 commits
-
-
Mauro Carvalho Chehab authored
drivers/media/platform/exynos-gsc/gsc-core.c:855:2: note: in expansion of macro 'pr_debug' pr_debug("ADDR: y= 0x%X cb= 0x%X cr= 0x%X ret= %d", ^ include/linux/dynamic_debug.h:64:16: warning: format '%X' expects argument of type 'unsigned int', but argument 4 has type 'dma _addr_t' [-Wformat=] static struct _ddebug __aligned(8) \ ^ Signed-off-by:Mauro Carvalho Chehab <m.chehab@samsung.com>
-
Mauro Carvalho Chehab authored
The needed bandwidth can be estimated using the symbol rate and the rolloff factor. This could be useful for the frontend drivers, as they don't need to calculate it themselves. Reported-by:
Antti Palosaari <crope@iki.fi> Signed-off-by:
-
Mauro Carvalho Chehab authored
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 authored
Shut up several warnings about invalid casting when printing the values of two pointers. Signed-off-by: -
Mauro Carvalho Chehab authored
The 'debug' name is known to cause conflicts with allyesconfig on several archs. So, localize its name. >> drivers/built-in.o:(.bss+0xc7ee2c): multiple definition of `debug' arch/x86/built-in.o:(.entry.text+0xf78): first defined here ld: Warning: size of symbol `debug' changed from 86 in arch/x86/built-in.o to 4 in drivers/built-in.o While here, fix a wrong file name reference Reported-by:
kbuild test robot <fengguang.wu@intel.com> Signed-off-by:
-
Mauro Carvalho Chehab authored
drivers/media/platform/soc_camera/atmel-isi.c: In function 'start_streaming': drivers/media/platform/soc_camera/atmel-isi.c:397:26: warning: large integer implicitly truncated to unsigned type [-Woverflow] isi_writel(isi, ISI_INTDIS, ~0UL); ^ Reported-by: -
Mauro Carvalho Chehab authored
Instead of using u32 for DMA address, use the proper Kernel type for it. drivers/media/platform/soc_camera/atmel-isi.c: In function 'atmel_isi_probe': >> drivers/media/platform/soc_camera/atmel-isi.c:981:26: warning: passing argument 3 of 'dma_alloc_attrs' from incompatible pointer type isi->p_fb_descriptors = dma_alloc_coherent(&pdev->dev, ^ Reported-by: -
Mauro Carvalho Chehab authored
drivers/media/platform/ti-vpe/vpdma.c: In function 'vpdma_alloc_desc_buf': >> drivers/media/platform/ti-vpe/vpdma.c:332:10: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast] WARN_ON((u32) buf->addr & VPDMA_DESC_ALIGN); ^ Reported-by: -
Mauro Carvalho Chehab authored
drivers/media/platform/ti-vpe/vpdma.c: In function 'dump_dtd': include/linux/dynamic_debug.h:64:16: warning: format '%x' expects argument of type 'unsigned int', but argument 3 has type 'dma_addr_t' [-Wformat=] static struct _ddebug __aligned(8) \ ^ include/linux/dynamic_debug.h:76:2: note: in expansion of macro 'DEFINE_DYNAMIC_DEBUG_METADATA' DEFINE_DYNAMIC_DEBUG_METADATA(descriptor, fmt); \ ^ include/linux/printk.h:263:2: note: in expansion of macro 'dynamic_pr_debug' dynamic_pr_debug(fmt, ##__VA_ARGS__) ^ >> drivers/media/platform/ti-vpe/vpdma.c:587:2: note: in expansion of macro 'pr_debug' pr_debug("word2: start_addr = 0x%08x\n", dtd->start_addr); ^ Reported-by: -
Mauro Carvalho Chehab authored
drivers/media/platform/exynos-gsc/gsc-m2m.c: In function 'gsc_m2m_reqbufs': drivers/media/platform/exynos-gsc/gsc-m2m.c:365:20: warning: variable 'frame' s et but not used [-Wunused-but-set-variable] struct gsc_frame *frame; ^ Signed-off-by: -
Mauro Carvalho Chehab authored
drivers/media/platform/exynos-gsc/gsc-core.c: In function 'gsc_probe': drivers/media/platform/exynos-gsc/gsc-core.c:1089:2: warning: comparison is alw ays false due to limited range of data type [-Wtype-limits] if (gsc->id < 0 || gsc->id >= drv_data->num_entities) { ^ gsc->id is declared as u16, so it should always be a positive value. Signed-off-by: -
Mauro Carvalho Chehab authored
drivers/media/platform/davinci/dm355_ccdc.c:463:5: warning: no previous prototy pe for 'ccdc_write_dfc_entry' [-Wmissing-prototypes] int ccdc_write_dfc_entry(int index, struct ccdc_vertical_dft *dfc) ^ Signed-off-by: -
Mauro Carvalho Chehab authored
drivers/media/platform/davinci/dm644x_ccdc.c:133:6: warning: no previous protot ype for 'ccdc_setwin' [-Wmissing-prototypes] void ccdc_setwin(struct v4l2_rect *image_win, ^ drivers/media/platform/davinci/dm644x_ccdc.c:373:6: warning: no previous protot ype for 'ccdc_config_ycbcr' [-Wmissing-prototypes] void ccdc_config_ycbcr(void) ^ drivers/media/platform/davinci/dm644x_ccdc.c:526:6: warning: no previous protot ype for 'ccdc_config_raw' [-Wmissing-prototypes] void ccdc_config_raw(void) ^ Signed-off-by: -
Mauro Carvalho Chehab authored
drivers/media/platform/davinci/vpif_capture.c: In function 'vpif_channel_isr': drivers/media/platform/davinci/vpif_capture.c:376:18: warning: variable 'field' set but not used [-Wunused-but-set-variable] enum v4l2_field field; ^ drivers/media/platform/davinci/vpif_capture.c: In function 'vpif_calculate_offs ets': drivers/media/platform/davinci/vpif_capture.c:536:23: warning: variable 'vpitch ' set but not used [-Wunused-but-set-variable] unsigned int hpitch, vpitch, sizeimage; ^ Signed-off-by: -
Mauro Carvalho Chehab authored
drivers/media/platform/davinci/vpif_display.c: In function 'vpif_channel_isr': drivers/media/platform/davinci/vpif_display.c:363:18: warning: variable 'field' set but not used [-Wunused-but-set-variable] enum v4l2_field field; ^ drivers/media/platform/davinci/vpif_display.c: In function 'vpif_calculate_offs ets': drivers/media/platform/davinci/vpif_display.c:505:23: warning: variable 'vpitch ' set but not used [-Wunused-but-set-variable] unsigned int hpitch, vpitch, sizeimage; ^ drivers/media/platform/davinci/vpif_display.c: In function 'vpif_set_output': drivers/media/platform/davinci/vpif_display.c:816:27: warning: variable 'subdev _info' set but not used [-Wunused-but-set-variable] struct vpif_subdev_info *subdev_info = NULL; Signed-off-by:
-
- 21 Aug, 2014 25 commits
-
-
Randy Dunlap authored
Fix build when CONFIG_INPUT_EVDEV=m and DVB_AV7110=y. Only build av7110_ir.c when CONFIG_INPUT_EVDEV is compatible with CONFIG_DVB_AV7110. Fixes these build errors: drivers/built-in.o: In function `input_sync': av7110_ir.c:(.text+0x1223ac): undefined reference to `input_event' drivers/built-in.o: In function `av7110_emit_key': av7110_ir.c:(.text+0x12247c): undefined reference to `input_event' av7110_ir.c:(.text+0x122495): undefined reference to `input_event' av7110_ir.c:(.text+0x122569): undefined reference to `input_event' av7110_ir.c:(.text+0x1225a7): undefined reference to `input_event' drivers/built-in.o:av7110_ir.c:(.text+0x122629): more undefined references to `input_event' follow drivers/built-in.o: In function `av7110_ir_init': (.text+0x1227e4): undefined reference to `input_allocate_device' drivers/built-in.o: In function `av7110_ir_init': (.text+0x12298f): undefined reference to `input_register_device' drivers/built-in.o: In function `av7110_ir_init': (.text+0x12299e): undefined reference to `input_free_device' drivers/built-in.o: In function `av7110_ir_exit': (.text+0x122a94): undefined reference to `input_unregister_device' drivers/built-in.o: In function `av7110_detach': av7110.c:(.text+0x228d4a): undefined reference to `av7110_ir_exit' drivers/built-in.o: In function `arm_thread': av7110.c:(.text+0x22a404): undefined reference to `av7110_check_ir_config' av7110.c:(.text+0x22a626): undefined reference to `av7110_check_ir_config' drivers/built-in.o: In function `av7110_attach': av7110.c:(.text+0x22b08c): undefined reference to `av7110_ir_init' Signed-off-by:
Randy Dunlap <rdunlap@infradead.org> Reported-by:
Jim Davis <jim.epost@gmail.com> Reported-by:
-
Mauro Carvalho Chehab authored
Now that alsa code is part of the driver, it can be compiled only if alsa is enabled. drivers/built-in.o: In function `snd_usbtv_hw_free': >> usbtv-audio.c:(.text+0x21eb55): undefined reference to `snd_pcm_lib_free_pages' drivers/built-in.o: In function `snd_usbtv_hw_params': >> usbtv-audio.c:(.text+0x21eb72): undefined reference to `snd_pcm_lib_malloc_pages' drivers/built-in.o: In function `usbtv_audio_urb_received': >> usbtv-audio.c:(.text+0x21ed66): undefined reference to `snd_pcm_link_rwlock' >> usbtv-audio.c:(.text+0x21ed9f): undefined reference to `snd_pcm_link_rwlock' >> usbtv-audio.c:(.text+0x21edf5): undefined reference to `snd_pcm_period_elapsed' drivers/built-in.o: In function `usbtv_audio_init': >> (.text+0x21f00a): undefined reference to `snd_card_new' drivers/built-in.o: In function `usbtv_audio_init': >> (.text+0x21f0a2): undefined reference to `snd_pcm_new' drivers/built-in.o: In function `usbtv_audio_init': >> (.text+0x21f0e5): undefined reference to `snd_pcm_set_ops' drivers/built-in.o: In function `usbtv_audio_init': >> (.text+0x21f103): undefined reference to `snd_pcm_lib_preallocate_pages_for_all' drivers/built-in.o: In function `usbtv_audio_init': >> (.text+0x21f10c): undefined reference to `snd_card_register' drivers/built-in.o: In function `usbtv_audio_init': >> (.text+0x21f12a): undefined reference to `snd_card_free' drivers/built-in.o: In function `usbtv_audio_free': >> (.text+0x21f15c): undefined reference to `snd_card_free' >> drivers/built-in.o:(.data+0x43250): undefined reference to `snd_pcm_lib_ioctl' Reported-by:
-
Shuah Khan authored
au0828 doesn't resume correctly and TV tuning fails with xc_set_signal_source(0) failed message. Change au0828 dvb suspend and resume interfaces to suspend and resume frontend during suspend and resume respectively. dvb_frontend_suspend() suspends tuner and fe using tuner and fe ops. dvb_frontend_resume() resumes fe and tuner using fe and tuner ops ini before waking up the frontend. With this change HVR950Q suspend and resume work when system gets suspended when digital function is tuned to a channel and with active TV stream, and after resume it went right back to active TV stream. Signed-off-by:
Shuah Khan <shuah.kh@samsung.com> Signed-off-by:
-
Frank Schaefer authored
The correct field order in progressive mode is V4L2_FIELD_NONE, not V4L2_FIELD_INTERLACED. Cc: <stable@vger.kernel.org> Signed-off-by:
Frank Schäfer <fschaefer.oss@googlemail.com> Signed-off-by:
-
Frank Schaefer authored
When a new video frame is started, the driver takes the next video buffer from the list of active buffers and moves it to dev->usb_ctl.vid_buf / dev->usb_ctl.vbi_buf for further processing. On streaming stop we currently only give back the pending buffers from the list but not the ones which are currently processed. This causes the following warning from the vb2 core since kernel 3.15: ... ------------[ cut here ]------------ WARNING: CPU: 1 PID: 2284 at drivers/media/v4l2-core/videobuf2-core.c:2115 __vb2_queue_cancel+0xed/0x150 [videobuf2_core]() [...] Call Trace: [<c0769c46>] dump_stack+0x48/0x69 [<c0245b69>] warn_slowpath_common+0x79/0x90 [<f925e4ad>] ? __vb2_queue_cancel+0xed/0x150 [videobuf2_core] [<f925e4ad>] ? __vb2_queue_cancel+0xed/0x150 [videobuf2_core] [<c0245bfd>] warn_slowpath_null+0x1d/0x20 [<f925e4ad>] __vb2_queue_cancel+0xed/0x150 [videobuf2_core] [<f925fa35>] vb2_internal_streamoff+0x35/0x90 [videobuf2_core] [<f925fac5>] vb2_streamoff+0x35/0x60 [videobuf2_core] [<f925fb27>] vb2_ioctl_streamoff+0x37/0x40 [videobuf2_core] [<f8e45895>] v4l_streamoff+0x15/0x20 [videodev] [<f8e4925d>] __video_do_ioctl+0x23d/0x2d0 [videodev] [<f8e49020>] ? video_ioctl2+0x20/0x20 [videodev] [<f8e48c63>] video_usercopy+0x203/0x5a0 [videodev] [<f8e49020>] ? video_ioctl2+0x20/0x20 [videodev] [<c039d0e7>] ? fsnotify+0x1e7/0x2b0 [<f8e49012>] video_ioctl2+0x12/0x20 [videodev] [<f8e49020>] ? video_ioctl2+0x20/0x20 [videodev] [<f8e4461e>] v4l2_ioctl+0xee/0x130 [videodev] [<f8e44530>] ? v4l2_open+0xf0/0xf0 [videodev] [<c0378de2>] do_vfs_ioctl+0x2e2/0x4d0 [<c0368eec>] ? vfs_write+0x13c/0x1c0 [<c0369a8f>] ? vfs_writev+0x2f/0x50 [<c0379028>] SyS_ioctl+0x58/0x80 [<c076fff3>] sysenter_do_call+0x12/0x12 ---[ end trace 5545f934409f13f4 ]--- ... Many thanks to Hans Verkuil, whose recently added check in the vb2 core unveiled this long standing issue and who has investigated it further. Cc: <stable@vger.kernel.org> Signed-off-by:
-
Axel Lin authored
So we can remove the same defines in the driver code. Signed-off-by:
Axel Lin <axel.lin@ingics.com> Signed-off-by:
-
Axel Lin authored
So we can remove the same defines in the driver code. Signed-off-by:
-
Axel Lin authored
Fix a copy-paste bug when converting to the control framework. Fixes: commit 5d478e0d ("[media] tda7432: convert to the control framework") Signed-off-by:
-
Axel Lin authored
So we can remove the same defines in the driver code. Signed-off-by:
-
Axel Lin authored
So we can remove the same defines in the driver code. Signed-off-by:
-
Axel Lin authored
So we can remove the same defines in the driver code. Signed-off-by:
-
Axel Lin authored
So we can remove the same defines in the driver code. Signed-off-by:
Jonathan Corbet <corbet@lwn.net> Signed-off-by:
-
Sakari Ailus authored
Constify event type constants and correct motion detection event number (it's 6, not 5). Signed-off-by:
Sakari Ailus <sakari.ailus@linux.intel.com> Acked-by:
Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by:
-
Ulrich Eckhardt authored
Make the front panel buttons working after another button on the remote was pressed. Signed-off-by:
Ulrich Eckhardt <uli@uli-eckhardt.de> Signed-off-by:
-
Ulrich Eckhardt authored
Add the key table for the Thermaltake DH-102 to the USB-Id 15c2:0034. Signed-off-by:
-
Ulrich Eckhardt authored
This patch defines the keytables per USB Device ID. Signed-off-by:
-
Vitaly Osipov authored
It makes more sense to return PTR_ERR(iss->iss_ctrlclk) here. The current code looks like an oversight in pasting the block just above this one. Signed-off-by:
Vitaly Osipov <vitaly.osipov@gmail.com> Acked-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by:
-
Federico Simoncelli authored
Add an ALSA handler inside usbtv module, in order to make audio to work with those devices. Signed-off-by:
Federico Simoncelli <fsimonce@redhat.com> Tested-by:
Lubomir Rintel <lkundrak@v3.sk> Signed-off-by:
-
Andreas Ruprecht authored
In the list of subdirectories compiled, b2c2/ appears twice. This patch removes one of the appearances. Signed-off-by:
Andreas Ruprecht <rupran@einserver.de> Signed-off-by:
-
Axel Lin authored
Using the managed function the kfree() calls can be removed from the probe error path and the remove handler. Signed-off-by:
Lad, Prabhakar <prabhakar.csengg@gmail.com> Signed-off-by:
-
Geert Uytterhoeven authored
Signed-off-by:
Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by:
-
Geert Uytterhoeven authored
Signed-off-by:
-
Hans Verkuil authored
Modern kernels enable dynamic printk support, which is fine, except when it is combined with a debug module option. Enabling debug in videobuf2-core now produces no debugging unless it is also enabled through the dynamic printk support in debugfs. Either use a debug module option + pr_info, or use pr_debug without a debug module option. In this case the fact that you can set various debug levels is very useful, so I believe that for videobuf2-core.c we should use pr_info. The mix of the two is very confusing: I've spent too much time already trying to figure out why I am not seeing any debug output in the kernel log when I do: echo 1 >/sys/modules/videobuf2_core/parameters/debug Signed-off-by:
-
Hans Verkuil authored
The order of the last two fields in the G/S_EDID specification was swapped from what is in the actual struct. Fix this. Signed-off-by:
-
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:
Marek Szyprowski <m.szyprowski@samsung.com> Signed-off-by:
-
