linux-media.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Archit Taneja <archit@ti.com>
To: Jan Kara <jack@suse.cz>
Cc: <linux-media@vger.kernel.org>,
	Tomi Valkeinen <tomi.valkeinen@ti.com>,
	Mauro Carvalho Chehab <m.chehab@samsung.com>
Subject: Re: Handling of VM_IO vma in omap_vout_uservirt_to_phys()
Date: Mon, 21 Oct 2013 14:47:39 +0530	[thread overview]
Message-ID: <5264F133.9000407@ti.com> (raw)
In-Reply-To: <20131018131100.GB20660@quack.suse.cz>

On Friday 18 October 2013 06:41 PM, Jan Kara wrote:
> On Fri 18-10-13 14:59:17, Archit Taneja wrote:
>> Hi,
>>
>> On Friday 18 October 2013 03:46 AM, Jan Kara wrote:
>>>    Hello,
>>>
>>>    I was auditing get_user_pages() users and I've noticed that
>>> omap_vout_uservirt_to_phys() is apparently called for arbitrary address
>>> passed from userspace. If this address is in VM_IO vma, we use
>>> vma->vm_pgoff for mapping the virtual address to a physical address.
>>> However I don't think this is a generally valid computation for arbitrary
>>> VM_IO vma. So do we expect vma to come from a particular source where this
>>> is true? If yes, where do we expect vma comes from? Thanks for
>>> clarification.
>>
>> I don't know much about this domain, so I might be wrong here.
>>
>> The function omap_vout_uservirt_to_phys() is used in the mode
>> 'V4L2_MEMORY_USERPTR', to recieve a virtual address from the user.
>>
>> The driver hardware only works with physically contiguous buffers.
>> So I'm guessing this vma maps to a buffer mmaped by the user
>> application by some other device(like a camera or something). This
>> way, the user doesn't need to copy the buffer between the 2 devices.
>> I guess the computation works in that case. We don't have any safety
>> checks for this though.
>    OK, so you really expect vma to be setup in a particular way. In
> videobuf2 framework this seems to correspond to what
> drivers/media/v4l2-core/videobuf2-vmalloc.c is doing (although that one is
> checking the range is really physically contiguous in
> vb2_get_contig_userptr()).
>
>> This driver is currenlty using the videobuf() framework, we would
>> eventually switch to videobuf2(), and hopefully this code shouldn't
>> even exist then.
>    This is good to know but if that isn't happening soon I guess I'll
> convert the code somehow because I want to do some changes to the way
> get_user_pages() is called.

I think the conversion will take some time.

I don't think we have tested user pointer support on omap_vout for quite 
a while. Anyway, I can still test to see if the change works fine or not.

Archit


      reply	other threads:[~2013-10-21  9:18 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-10-17 22:16 Handling of VM_IO vma in omap_vout_uservirt_to_phys() Jan Kara
2013-10-18  9:29 ` Archit Taneja
2013-10-18 13:11   ` Jan Kara
2013-10-21  9:17     ` Archit Taneja [this message]

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=5264F133.9000407@ti.com \
    --to=archit@ti.com \
    --cc=jack@suse.cz \
    --cc=linux-media@vger.kernel.org \
    --cc=m.chehab@samsung.com \
    --cc=tomi.valkeinen@ti.com \
    /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).