public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Brian Gerst <bgerst@didntduck.org>
To: Timur Tabi <timur.tabi@ammasso.com>
Cc: Gerd Knorr <kraxel@suse.de>, linux-kernel@vger.kernel.org
Subject: Re: Will __pa(vmalloc()) ever work?
Date: Tue, 31 May 2005 16:44:49 -0400	[thread overview]
Message-ID: <429CCCC1.8020106@didntduck.org> (raw)
In-Reply-To: <429CB429.8090008@ammasso.com>

Timur Tabi wrote:
> Gerd Knorr wrote:
> 
>> Can you fix that?  If so, try that.  Would be the best.
> 
> 
> No, I cannot.  The memory is passed to my driver from some other driver 
> that I do not
> control.

What kind of driver are you writing, and what other driver is giving you 
this address?

>> I think you can't.  What is "anywhere else"?  Does that include
>> userspace addresses?
> 
> No, but it might include the stack.
> 
>> Not sure how portable that is, but comparing the vaddr against
>> the vmalloc address space could work.  There are macros for
>> that, VMALLOC_START & VMALLOC_END IIRC.
> 
> 
> Thanks, I'll try that.
> 
> I still haven't gotten an answer to my question about whether 
> pgd/pud/pmd/pte_offset will obtain the physical address for a kmalloc'd 
> buffer.

Walking the page tables isn't guaranteed to work for all addresses on 
all arches.  On some you have to deal with large pages, on others you 
have parts of the address space that are mapped by different mechanisms. 
  This isn't something that drivers should be getting involved in.

--
				Brian Gerst

      parent reply	other threads:[~2005-05-31 20:44 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
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 [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=429CCCC1.8020106@didntduck.org \
    --to=bgerst@didntduck.org \
    --cc=kraxel@suse.de \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox