All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jiri Slaby <jirislaby@gmail.com>
To: Guillermo Marcus <marcus@ti.uni-mannheim.de>
Cc: linux-kernel@vger.kernel.org
Subject: Re: mmaping a kernel buffer to user space
Date: Tue, 31 Oct 2006 17:00:59 +0100	[thread overview]
Message-ID: <4547733B.9040801@gmail.com> (raw)
In-Reply-To: <4547150F.8070408@ti.uni-mannheim.de>

Guillermo Marcus wrote:
> Hi all,
> 
> I recently run with the following situation while developing a PCI
> driver. The driver allocates memory for a PCI device using
> pci_alloc_consistent as this memory is going to be used to perform DMA
> transfers. To pass the data from/to the user application, I mmap the
> buffer into userspace. However, if I try to use remap_pfn_range
> (>=2.6.10) or the older remap_page_range(<=2.6.9) for mmaping, it ends
> up creating a new buffer, because they do not support RAM mapping, then
> pagefaulting to the VMA and by default allocating new pages. Therefore,
> I had to implement the nopage method and mmap one page at a time as they
> fault.
> 
> However, to my point of view, this is unnecessary. The memory is already
> allocated, the memory is locked because it is consistent, and it may be
> a (very small) performance and stability issue to do them one-by-one.
> Why can't I simply mmap it all at once? am I missing some function? More
> important, why can't remap_{pfn/page}_range handle it?

Piece of code please. pci_alloc_consistent calls __get_free_pages, and there
should be no problem with mmaping this area.

regards,
-- 
http://www.fi.muni.cz/~xslaby/            Jiri Slaby
faculty of informatics, masaryk university, brno, cz
e-mail: jirislaby gmail com, gpg pubkey fingerprint:
B674 9967 0407 CE62 ACC8  22A0 32CC 55C3 39D4 7A7E

  reply	other threads:[~2006-10-31 16:01 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-10-31  9:19 mmaping a kernel buffer to user space Guillermo Marcus
2006-10-31 16:00 ` Jiri Slaby [this message]
2006-10-31 16:25   ` Guillermo Marcus
2006-10-31 16:49     ` Jiri Slaby
2006-10-31 17:08       ` Franck Bui-Huu
2006-10-31 19:44       ` Miguel Ojeda
2006-10-31 19:22   ` Russell King
2006-10-31 19:36     ` Jiri Slaby
2006-10-31 16:10 ` Rolf Offermanns
2006-10-31 16:33   ` Guillermo Marcus
2006-11-01 11:11 ` Rolf Offermanns
2006-11-01 12:58   ` Guillermo Marcus Martinez
2006-11-01 14:00     ` yogeshwar sonawane
2006-11-01 15:06       ` Guillermo Marcus Martinez
2006-11-02  8:31     ` Russell King
2006-11-02 11:31       ` Guillermo Marcus

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=4547733B.9040801@gmail.com \
    --to=jirislaby@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=marcus@ti.uni-mannheim.de \
    /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.