I can confirm this. I was running following ffmpeg command:
ffmpeg -s 640x480 -f video4linux2 -i /dev/video0 http://127.0.0.1:8090/webcam.ffm

$ uname -a
Linux ostash 3.15.0-gentoo-ostash32 #1 SMP Mon Jun 9 22:17:33 EEST 2014 i686 AMD Athlon(tm) II P320 Dual-Core Processor AuthenticAMD GNU/Linux

[ 8181.706753] BUG: unable to handle kernel paging request at 5bd57140
[ 8181.706932] IP: [<f92f8d90>] __vb2_queue_alloc+0x70/0x440 [videobuf2_core]
[ 8181.707106] *pde = 00000000 
[ 8181.707180] Oops: 0002 [#1] SMP 
[ 8181.707266] Modules linked in: ctr ccm af_packet snd_hrtimer hid_generic usbhid hid mousedev uvcvideo videobuf2_vmalloc videobuf2_memops videobuf2_core videodev broadcom kvm_amd kvm arc4 brcmsmac cordic brcmutil radeon mac80211 cfg80211 cfbfillrect cfbimgblt cfbcopyarea i2c_algo_bit drm_kms_helper tg3 ttm sr_mod drm ptp acer_wmi sparse_keymap led_class rfkill microcode agpgart cdrom pps_core bcma psmouse evdev libphy firmware_class snd_hda_codec_realtek snd_hda_codec_generic pcspkr k10temp snd_hda_codec_hdmi ohci_pci snd_hda_intel snd_hda_controller snd_hda_codec ehci_pci ohci_hcd snd_pcm ehci_hcd snd_timer battery usbcore snd i2c_piix4 thermal rtc_cmos i2c_core usb_common soundcore video backlight wmi ac button acpi_cpufreq processor thermal_sys hwmon unix
[ 8181.709221] CPU: 1 PID: 29723 Comm: ffmpeg Not tainted 3.15.0-gentoo-ostash32 #1
[ 8181.709391] Hardware name: Acer /, BIOS V2.14 07/27/2011
[ 8181.709515] task: f6078000 ti: e96d0000 task.ti: e96d0000
[ 8181.709640] EIP: 0060:[<f92f8d90>] EFLAGS: 00010206 CPU: 1
[ 8181.709769] EIP is at __vb2_queue_alloc+0x70/0x440 [videobuf2_core]
[ 8181.709911] EAX: d9af602d EBX: d9af6000 ECX: 000000bd EDX: 00000000
[ 8181.710053] ESI: d9af6800 EDI: d9af6800 EBP: f517f088 ESP: e96d1d7c
[ 8181.710194]  DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
[ 8181.710317] CR0: 8005003b CR2: 5bd57140 CR3: 27e78000 CR4: 000007d0
[ 8181.710457] Stack:
[ 8181.710505]  e96d1e78 c105d4de 00000000 00000000 00000022 00000001 d9af6800 d9af6800
[ 8181.710722]  00000001 00000100 f517f088 e96d1e70 f932f8e0 e96d1e78 f92f9697 00000001
[ 8181.710940]  f517f188 f517f168 f517f188 f517f168 00000100 00000001 f517f1b0 f517f088
[ 8181.711157] Call Trace:
[ 8181.711225]  [<c105d4de>] ? __wake_up+0x3e/0x60
[ 8181.711338]  [<f932f8e0>] ? uvc_entity_by_id+0x40/0x40 [uvcvideo]
[ 8181.711483]  [<f92f9697>] ? __reqbufs.isra.16+0x167/0x300 [videobuf2_core]
[ 8181.711646]  [<f932fb98>] ? uvc_alloc_buffers+0x28/0x50 [uvcvideo]
[ 8181.711793]  [<f9331841>] ? uvc_v4l2_do_ioctl+0xe11/0x1280 [uvcvideo]
[ 8181.711952]  [<f92d3b5e>] ? video_usercopy+0x1ae/0x400 [videodev]
[ 8181.712100]  [<f9330198>] ? uvc_v4l2_ioctl+0x28/0x60 [uvcvideo]
[ 8181.712240]  [<f9330a30>] ? uvc_v4l2_open+0x130/0x130 [uvcvideo]
[ 8181.712384]  [<f92ce675>] ? v4l2_ioctl+0xf5/0x130 [videodev]
[ 8181.712521]  [<f92ce580>] ? v4l2_open+0xf0/0xf0 [videodev]
[ 8181.712654]  [<c10da59f>] ? do_vfs_ioctl+0x31f/0x500
[ 8181.712772]  [<c10dd6d2>] ? dput+0x22/0x140
[ 8181.712874]  [<c10ca200>] ? do_sys_open+0x190/0x200
[ 8181.712991]  [<c10da7c3>] ? SyS_ioctl+0x43/0x80
[ 8181.713102]  [<c12e3a0a>] ? sysenter_do_call+0x12/0x26
[ 8181.713221] Code: 10 03 85 b4 00 00 00 89 07 8b 45 00 89 47 04 8b 44 24 20 89 47 30 48 74 52 8b 9d b4 00 00 00 8b 44 24 10 ff 44 24 10 8d 44 03 0c <89> 7c 85 04 8b 44 24 10 3b 44 24 24 0f 84 2a 02 00 00 8b 45 20
[ 8181.714032] EIP: [<f92f8d90>] __vb2_queue_alloc+0x70/0x440 [videobuf2_core] SS:ESP 0068:e96d1d7c
[ 8181.714243] CR2: 000000005bd57140
[ 8181.745400] ---[ end trace 47d8ef8358cc86fc ]---

I also have a similar issue when using ffmpeg with a uvcvideo webcam:

[   87.646678] BUG: unable to handle kernel paging request at 93e60540
[   87.646843] IP: [<f99eb98c>] __vb2_queue_alloc+0x6c/0x450 [videobuf2_core]
[   87.646985] *pdpt = 00000000290f4001 *pde = 0000000000000000 
[   87.647098] Oops: 0002 [#1] SMP 
[   87.647151] Modules linked in: microcode nfsv3 sha256_generic cbc snd_usb_audio snd_usbmidi_lib usbhid snd_rawmidi psmouse sata_via sr_mod i2c_piix4 cdrom 8250 serial_core button uvcvideo videobuf2_vmalloc videobuf2_memops videobuf2_core videodev cifs dm_crypt dm_mod md5 ecryptfs nfs nfsd lockd sunrpc snd_hda_codec_realtek snd_hda_codec_generic snd_hda_codec_hdmi snd_hda_intel snd_hda_controller snd_hda_codec snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss snd_mixer_oss snd_hwdep snd_pcm snd_timer snd soundcore brd loop k10temp acpi_cpufreq processor thermal_sys pata_atiixp eeprom virtio_blk virtio_ring virtio
[   87.648699] CPU: 0 PID: 1826 Comm: ffmpeg Not tainted 3.15.0-rc2-00023-g7040b6d #13
[   87.648844] Hardware name: To be filled by O.E.M. To be filled by O.E.M./M5A97 PRO, BIOS 1604 10/16/2012
[   87.649030] task: eeec6c00 ti: e91f8000 task.ti: e91f8000
[   87.649126] EIP: 0060:[<f99eb98c>] EFLAGS: 00010246 CPU: 0
[   87.649254] EIP is at __vb2_queue_alloc+0x6c/0x450 [videobuf2_core]
[   87.649368] EAX: e971c42d EBX: e971c400 ECX: 33d6c000 EDX: 00000000
[   87.649483] ESI: 00000021 EDI: e971c800 EBP: ee1ef488 ESP: e91f9d78
[   87.649598]  DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
[   87.649693] CR0: 8005003b CR2: 93e60540 CR3: 2d905000 CR4: 000007f0
[   87.649807] Stack:
[   87.649825]  e91f9e70 c10ac7fe 00000000 00000000 00000001 00000021 e971c848 ee1ef488
[   87.650006]  00000001 00000100 ee1ef488 e91f9e68 f9a198b0 e91f9e70 f99ec1d6 00000001
[   87.650186]  ee1ef588 ee1ef568 ee1ef588 ee1ef568 00000100 00000001 ee1ef488 ee1ef5b0
[   87.650367] Call Trace:
[   87.650430]  [<c10ac7fe>] ? __wake_up+0x3e/0x60
[   87.650512]  [<f9a198b0>] ? uvc_entity_by_id+0x50/0x50 [uvcvideo]
[   87.650626]  [<f99ec1d6>] ? __reqbufs.isra.16+0x146/0x290 [videobuf2_core]
[   87.650758]  [<f9a19b78>] ? uvc_alloc_buffers+0x28/0x50 [uvcvideo]
[   87.650875]  [<f9a1b6a9>] ? uvc_v4l2_do_ioctl+0xd59/0x1180 [uvcvideo]
[   87.650997]  [<c111c50a>] ? kfree+0xda/0xe0
[   87.651072]  [<f99c77fb>] ? video_usercopy+0x24b/0x420 [videodev]
[   87.651187]  [<f99c77fb>] ? video_usercopy+0x24b/0x420 [videodev]
[   87.651303]  [<f99c7847>] ? video_usercopy+0x297/0x420 [videodev]
[   87.651421]  [<f8ae33f3>] ? snd_pcm_oss_capture_position_fixup+0x53/0x60 [snd_pcm_oss]
[   87.651575]  [<f9a1a178>] ? uvc_v4l2_ioctl+0x28/0x60 [uvcvideo]
[   87.651712]  [<f9a1a950>] ? uvc_v4l2_open+0x130/0x130 [uvcvideo]
[   87.651826]  [<f99c26c5>] ? v4l2_ioctl+0x125/0x180 [videodev]
[   87.651933]  [<f99c25a0>] ? v4l2_open+0x110/0x110 [videodev]
[   87.652036]  [<c1136cab>] ? do_vfs_ioctl+0x2fb/0x500
[   87.652125]  [<c1125644>] ? do_sys_open+0x194/0x210
[   87.652211]  [<c1125644>] ? do_sys_open+0x194/0x210
[   87.652296]  [<c1136ef3>] ? SyS_ioctl+0x43/0x80
[   87.652379]  [<c150a550>] ? sysenter_do_call+0x12/0x26
[   87.652466] Code: 00 8b 44 24 14 03 85 b4 00 00 00 89 07 8b 45 00 89 47 04 8b 44 24 20 89 47 30 48 74 52 8b 74 24 14 8b 9d b4 00 00 00 8d 44 33 0c <89> 7c 85 04 89 f0 40 3b 44 24 24 89 44 24 14 0f 84 40 02 00 00
[   87.653186] EIP: [<f99eb98c>] __vb2_queue_alloc+0x6c/0x450 [videobuf2_core] SS:ESP 0068:e91f9d78
[   87.653368] CR2: 0000000093e60540
[   87.711719] ---[ end trace bb55fc85d78d8400 ]---

I have attempted to bisect my problem and I arrived at this commit:

root@Andromeda:/work/uvcvideo-bug/linux-stable# git bisect bad
1ee23fe07ee83a38ecee927e701f762888ada942 is first bad commit
commit 1ee23fe07ee83a38ecee927e701f762888ada942
Author: Takashi Iwai <tiwai@suse.de>
Date:   Fri May 2 18:17:06 2014 +0200

    ALSA: usb-audio: Fix deadlocks at resuming
    
    The recent addition of the USB audio mixer suspend/resume may lead to
    deadlocks when the driver tries to call usb_autopm_get_interface()
    recursively, since the function tries to sync with the finish of the
    other calls.  For avoiding it, introduce a flag indicating the resume
    operation and avoids the recursive usb_autopm_get_interface() calls
    during the resume.
    
    Reported-and-tested-by: Bryan Quigley <gquigs@gmail.com>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>

:040000 040000 2c875be2d21b9705fb71750c193c380308973aa6 c1ce3c698427b8024f6d069a13adb163f89e9a6b M	sound

Removing the changes from commit 1ee23fe07ee83a38ecee927e701f762888ada942 in the 3.15 stable kernel does stop the oops in my case, however not unexpectedly my uvcvideo webcam is not operational, mplayer for example is hanging in the /dev/video0 open.

Using:

mplayer tv:// -tv driver=v4l2:device=/dev/video0 -fps 30

I have performed another bisect and found my uvcvideo webcam stopped working with this commit:


root@Andromeda:/work/uvcvideo-bug/linux-stable# cat dmesg2.txt 
400362f1d8dcfda3562e80e88cfc2a92cffaf9bf is first bad commit
commit 400362f1d8dcfda3562e80e88cfc2a92cffaf9bf
Author: Takashi Iwai <tiwai@suse.de>
Date:   Mon Jan 20 16:51:16 2014 +0100

    ALSA: usb-audio: Resume mixer values properly
    
    Implement reset_resume callback so that the mixer values are properly
    restored.  Still no boot quirks are called, so it might not work well
    on some devices.
    
    Signed-off-by: Takashi Iwai <tiwai@suse.de>

:040000 040000 b11fe2b1239594a6528dd33b5fa0f5c13d45278e ffec5159801c47f8a289e587bc39e217fea51937 M	sound

I think this confirms that I am experiencing one of the lockup senarios reported in commit 1ee23fe07ee83a38ecee927e701f762888ada942.

The commit 1ee23fe07ee83 fixes the deadlock, thus likely now the real bug in v4l that has been blocked is revealed.  While bisecting, you should cherry-pick 1ee23fe07ee83.  Otherwise the test result isn't reliable at all.

Following Takashi Iwai's advice I have repeated the bisect with the changes from commit 1ee23fe07ee83 maintained in each step and this time the following commit was revealed:

root@Andromeda:/work/uvcvideo-bug/linux-stable# git bisect bad
b3379c6201bb3555298cdbf0aa004af260f2a6a4 is first bad commit
commit b3379c6201bb3555298cdbf0aa004af260f2a6a4
Author: Hans Verkuil <hans.verkuil@cisco.com>
Date:   Mon Feb 24 13:51:03 2014 -0300

    [media] vb2: only call start_streaming if sufficient buffers are queued
    
    In commit 02f142ecd24aaf891324ffba8527284c1731b561 support was added to
    start_streaming to return -ENOBUFS if insufficient buffers were queued
    for the DMA engine to start. The vb2 core would attempt calling
    start_streaming again if another buffer would be queued up.
    
    Later analysis uncovered problems with the queue management if start_streaming
    would return an error: the buffers are enqueued to the driver before the
    start_streaming op is called, so after an error they are never returned to
    the vb2 core. The solution for this is to let the driver return them to
    the vb2 core in case of an error while starting the DMA engine. However,
    in the case of -ENOBUFS that would be weird: it is not a real error, it
    just says that more buffers are needed. Requiring start_streaming to give
    them back only to have them requeued again the next time the application
    calls QBUF is inefficient.
    
    This patch changes this mechanism: it adds a 'min_buffers_needed' field
    to vb2_queue that drivers can set with the minimum number of buffers
    required to start the DMA engine. The start_streaming op is only called
    if enough buffers are queued. The -ENOBUFS handling has been dropped in
    favor of this new method.
    
    Drivers are expected to return buffers back to vb2 core with state QUEUED
    if start_streaming would return an error. The vb2 core checks for this
    and produces a warning if that didn't happen and it will forcefully
    reclaim such buffers to ensure that the internal vb2 core state remains
    consistent and all buffer-related resources have been correctly freed
    and all op calls have been balanced.
    
    __reqbufs() has been updated to check that at least min_buffers_needed
    buffers could be allocated. If fewer buffers were allocated then __reqbufs
    will free what was allocated and return -ENOMEM. Based on a suggestion from
    Pawel Osciak.
    
    __create_bufs() doesn't do that check, since the use of __create_bufs
    assumes some advance scenario where the user might want more control.
    Instead streamon will check if enough buffers were allocated to prevent
    streaming with fewer than the minimum required number of buffers.
    
    Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
    Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>

:040000 040000 1dbb84a4a931d9e95a2764b28b38eeb26c9c2381 5b2efe4a04ca1de7a261bb7c84d0d44e7121badb M	drivers
:040000 040000 d07ed2cc514e1b774c8129a370b588d8fa04f17c 4ee04fab4b001885db11157c45a7ac308ba9b17d M	include

Just build linux-3.16-rc1 and tried both ffmpeg and mplayer with my uvcvideo webcam and they both appear to work correctly (actually they appear to run better).

Tested with 3.16.0-rc4-next-20140707, works. Thanks for fixing.