[media] omap_vout: find_vma() needs ->mmap_sem held
authorAl Viro <viro@ZenIV.linux.org.uk>
Sun, 16 Dec 2012 19:04:46 +0000 (16:04 -0300)
committerMauro Carvalho Chehab <mchehab@redhat.com>
Sun, 6 Jan 2013 13:01:06 +0000 (11:01 -0200)
commit55ee64b30a38d688232e5eb2860467dddc493573
tree5776c2b2e2db1a231ff6097e1c3c235af7703285
parenta0a030bdbe612b7d8a941fba672300f7fc21b275
[media] omap_vout: find_vma() needs ->mmap_sem held

Walking rbtree while it's modified is a Bad Idea(tm); besides,
the result of find_vma() can be freed just as it's getting returned
to caller.  Fortunately, it's easy to fix - just take ->mmap_sem a bit
earlier (and don't bother with find_vma() at all if virtp >= PAGE_OFFSET -
in that case we don't even look at its result).

While we are at it, what prevents VIDIOC_PREPARE_BUF calling
v4l_prepare_buf() -> (e.g) vb2_ioctl_prepare_buf() -> vb2_prepare_buf() ->
__buf_prepare() -> __qbuf_userptr() -> vb2_vmalloc_get_userptr() -> find_vma(),
AFAICS without having taken ->mmap_sem anywhere in process?  The code flow
is bloody convoluted and depends on a bunch of things done by initialization,
so I certainly might've missed something...

Cc: stable@vger.kernel.org [2.6.35]
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Cc: Sakari Ailus <sakari.ailus@iki.fi>
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: Archit Taneja <archit@ti.com>
Cc: Prabhakar Lad <prabhakar.lad@ti.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
drivers/media/platform/omap/omap_vout.c