diff options
author | Jan Kara <jack@suse.cz> | 2015-07-13 14:55:43 (GMT) |
---|---|---|
committer | Mauro Carvalho Chehab <mchehab@osg.samsung.com> | 2015-08-16 16:01:10 (GMT) |
commit | 0f6e2825ce916eed882996bb6e9148c13ecebefd (patch) | |
tree | a08735e1623e370f32f255a27994cdb6e62c2284 /drivers/net/ppp/ppp_synctty.c | |
parent | 27c039750c8ff1297632e424a4674732cc4c3c70 (diff) | |
download | linux-0f6e2825ce916eed882996bb6e9148c13ecebefd.tar.xz |
[media] vb2: Push mmap_sem down to memops
Currently vb2 core acquires mmap_sem just around call to
__qbuf_userptr(). However since commit f035eb4e976ef5 (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: Jan Kara <jack@suse.cz>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
Diffstat (limited to 'drivers/net/ppp/ppp_synctty.c')
0 files changed, 0 insertions, 0 deletions