From: Arnd Bergmann <arnd@arndb.de>
To: Timur Tabi <timur.tabi@ammasso.com>
Cc: Christoph Hellwig <hch@infradead.org>, linux-kernel@vger.kernel.org
Subject: Re: Will __pa(vmalloc()) ever work?
Date: Fri, 27 May 2005 22:31:33 +0200 [thread overview]
Message-ID: <200505272231.34162.arnd@arndb.de> (raw)
In-Reply-To: <42977B0D.3040809@ammasso.com>
On Freedag 27 Mai 2005 21:54, Timur Tabi wrote:
> Christoph Hellwig wrote:
>
> > It will return the correct physical address for the start of the buffer.
No, not even that. If you do __pa(vmalloc()), the result will point outside of
the physical address space on most architectures.
> > But given that vmalloc is a non-contingous allocator that's pretty useless.
>
> So as long as the vmalloc'd memory fits inside one page, __pa() will always give the
> correct address? If so, then can't I just call __pa() for every page in the buffer and
> get a list of physical addresses? If I can do that, then how the memory be virtually
> contiguous but not physicall contiguous?
If the vmalloc'd memory fits into one page, you should not have used
vmalloc in the first place ;-). The only reason to ever use vmalloc
is if you can't get enough memory from alloc_pages reliably.
> > As are physical addresses for anything but low-level architecture code.
>
> I don't understand what that means.
It means that a device driver should never need to use __pa directly, because
physical addresses don't have a well-defined meaning outside of the memory
management. A driver should only need to deal with user virtual, kernel virtual
and bus virtual but never real addresses.
Also, no device driver should be using vmalloc either: vmalloc fragments
your address space, pins physical pages and eats small children.
Arnd <><
next prev parent reply other threads:[~2005-05-27 20:52 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-05-27 19:26 Will __pa(vmalloc()) ever work? Timur Tabi
2005-05-27 19:29 ` Christoph Hellwig
2005-05-27 19:54 ` Timur Tabi
2005-05-27 20:31 ` Arnd Bergmann [this message]
2005-05-28 16:16 ` Russell King
2005-05-30 9:38 ` Gerd Knorr
2005-05-31 15:51 ` Timur Tabi
2005-05-31 16:13 ` Gerd Knorr
2005-05-31 18:59 ` Timur Tabi
2005-05-31 20:01 ` Russell King
2005-05-31 20:44 ` Brian Gerst
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=200505272231.34162.arnd@arndb.de \
--to=arnd@arndb.de \
--cc=hch@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=timur.tabi@ammasso.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.