[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20130106110225.49b03d4e@infradead.org>
Date: Sun, 6 Jan 2013 11:02:25 -0200
From: Mauro Carvalho Chehab <mchehab@...radead.org>
To: Al Viro <viro@...IV.linux.org.uk>
Cc: linux-kernel@...r.kernel.org, linux-media@...r.kernel.org,
Laurent Pinchart <laurent.pinchart@...net.be>,
Archit Taneja <archit@...com>,
Prabhakar Lad <prabhakar.lad@...com>,
Sakari Ailus <sakari.ailus@....fi>
Subject: Re: [PATCH] omap_vout: find_vma() needs ->mmap_sem held
Hi Viro,
Em Sat, 15 Dec 2012 20:38:29 +0000
Al Viro <viro@...IV.linux.org.uk> escreveu:
> On Sat, Dec 15, 2012 at 08:12:37PM +0000, Al Viro wrote:
> > 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...
This driver is currently missing an active maintainer, as it is for an old
hardware (AFAIK, omap is now at version 4, and this is for the first one),
but I'm c/c a few developers that might help to test and analyze it.
In any case, /me is assuming that your patch is right (as nobody complained),
and I'm applying it right now on my tree. This will hopefully allow some
people to test.
Cheers,
Mauro
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists