Re: [PATCH] videobuf2: fix lockdep warning
Hello,
On 2014-07-31 13:52, Hans Verkuil wrote:
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]CPU0CPU1
[ 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] 82a6c9d0 8800af37fb00 819916a2
82a6c9d0
[ 403.118425] 8800af37fb40 810d5715 8802308e4200
[ 403.118429] 8802308e4a48 8802308e4a48 8802308e4200
0001
[ 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
Re: [PATCH] videobuf2: fix lockdep warning
That finally fixes the issue I reported last year.
http://www.spinics.net/lists/linux-media/msg70935.html
Tested-by: Antti Palosaari
On 07/31/2014 02:52 PM, Hans Verkuil wrote:
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]CPU0CPU1
[ 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] 82a6c9d0 8800af37fb00 819916a2
82a6c9d0
[ 403.118425] 8800af37fb40 810d5715 8802308e4200
[ 403.118429] 8802308e4a48 8802308e4a48 8802308e4200
0001
[ 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 r
[PATCH] videobuf2: fix lockdep warning
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]CPU0CPU1
[ 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] 82a6c9d0 8800af37fb00 819916a2
82a6c9d0
[ 403.118425] 8800af37fb40 810d5715 8802308e4200
[ 403.118429] 8802308e4a48 8802308e4a48 8802308e4200
0001
[ 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 wh
