From: Mauro Carvalho Chehab <mchehab@infradead.org>
To: Al Viro <viro@ZenIV.linux.org.uk>
Cc: linux-kernel@vger.kernel.org, linux-media@vger.kernel.org,
Laurent Pinchart <laurent.pinchart@skynet.be>,
Archit Taneja <archit@ti.com>,
Prabhakar Lad <prabhakar.lad@ti.com>,
Sakari Ailus <sakari.ailus@iki.fi>
Subject: Re: [PATCH] omap_vout: find_vma() needs ->mmap_sem held
Date: Sun, 6 Jan 2013 11:02:25 -0200 [thread overview]
Message-ID: <20130106110225.49b03d4e@infradead.org> (raw)
In-Reply-To: <20121215203828.GX4939@ZenIV.linux.org.uk>
Hi Viro,
Em Sat, 15 Dec 2012 20:38:29 +0000
Al Viro <viro@ZenIV.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
next prev parent reply other threads:[~2013-01-06 13:03 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-12-15 20:12 [PATCH] omap_vout: find_vma() needs ->mmap_sem held Al Viro
2012-12-15 20:38 ` Al Viro
2013-01-06 13:02 ` Mauro Carvalho Chehab [this message]
2013-01-07 14:03 ` Laurent Pinchart
2013-01-07 14:06 ` Laurent Pinchart
2012-12-16 20:01 ` Paul Bolle
2012-12-16 20:04 ` Al Viro
2013-01-07 14:15 ` Laurent Pinchart
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20130106110225.49b03d4e@infradead.org \
--to=mchehab@infradead.org \
--cc=archit@ti.com \
--cc=laurent.pinchart@skynet.be \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=prabhakar.lad@ti.com \
--cc=sakari.ailus@iki.fi \
--cc=viro@ZenIV.linux.org.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).