All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andi Kleen <ak@muc.de>
To: Jon Smirl <jonsmirl@gmail.com>
Cc: linux-kernel@vger.kernel.org,
	DRI Devel <dri-devel@lists.sourceforge.net>
Subject: Re: chasing the four level page table
Date: 6 Jan 2005 20:38:27 +0100
Date: Thu, 6 Jan 2005 20:38:26 +0100	[thread overview]
Message-ID: <20050106193826.GC47320@muc.de> (raw)
In-Reply-To: <9e47339105010610362fd7fffe@mail.gmail.com>

On Thu, Jan 06, 2005 at 01:36:46PM -0500, Jon Smirl wrote:
> On Thu, 06 Jan 2005 19:12:15 +0100, Andi Kleen <ak@muc.de> wrote:
> > Yes, you should use get_user_pages() instead if you access real memory.
> > If you try to find hardware mappings using that there is no ready
> > function for you right now, although I guess it could be added.
> 
> drm_follow_page is used like this:
> 
> offset = drm_follow_page(pt) | ((unsigned long) pt & ~PAGE_MASK);
> map = drm_lookup_map(offset, size, dev);
> if (map && map->type == _DRM_AGP) {
> 	vunmap(pt);
> 	return;
> }
> 
> I think pt is a user space address. In DRM AGP memory is mapped into
> kernel and user space so the user space address is being converted
> into a kernel space one. The kernel space one is used to verify that
> the address is a valid mapping to AGP space, if so the page is
> unmapped.  I didn't write this code so I'm not 100% sure of what is
> going on.

You can't use get_user_pages in this case because the AGP aperture
can be above mem_map.  If none of the callers take page_table_lock
already you would need to add that too. I guess from the context the lock
is not taken, but better double check.

Perhaps we should add a get_user_phys() or somesuch for this.

-Andi


  reply	other threads:[~2005-01-06 19:43 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-01-06 17:17 chasing the four level page table Jon Smirl
2005-01-06 18:12 ` Andi Kleen
2005-01-06 18:36   ` Jon Smirl
2005-01-06 19:38     ` Andi Kleen [this message]
2005-01-06 20:05       ` Jon Smirl
2005-01-06 21:41         ` Dave Jones
2005-01-08  5:22           ` Jon Smirl
2005-01-15  2:54             ` H. Peter Anvin
2005-01-15  3:37               ` Roland Dreier
2005-01-15  4:24               ` Andi Kleen
2005-01-15  5:59                 ` Jon Smirl

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=20050106193826.GC47320@muc.de \
    --to=ak@muc.de \
    --cc=dri-devel@lists.sourceforge.net \
    --cc=jonsmirl@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    /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.