All of lore.kernel.org
 help / color / mirror / Atom feed
From: Archit Taneja <archit@ti.com>
To: Jan Kara <jack@suse.cz>, <linux-media@vger.kernel.org>
Cc: 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: Fri, 18 Oct 2013 14:59:17 +0530	[thread overview]
Message-ID: <5260FF6D.3080305@ti.com> (raw)
In-Reply-To: <20131017221606.GA20365@quack.suse.cz>

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.

This driver is currenlty using the videobuf() framework, we would 
eventually switch to videobuf2(), and hopefully this code shouldn't even 
exist then.

Archit


  reply	other threads:[~2013-10-18  9:30 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 [this message]
2013-10-18 13:11   ` Jan Kara
2013-10-21  9:17     ` Archit Taneja

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=5260FF6D.3080305@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.