[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1233790920.16368.4.camel@gaiman>
Date: Wed, 04 Feb 2009 15:42:00 -0800
From: Eric Anholt <eric@...olt.net>
To: Jesse Barnes <jbarnes@...tuousgeek.org>
Cc: Thomas Hellström <thomas@...pmail.org>,
DRI <dri-devel@...ts.sourceforge.net>,
Linux Kernel <linux-kernel@...r.kernel.org>
Subject: Re: Gem GTT mmaps..
On Wed, 2009-02-04 at 15:02 -0800, Jesse Barnes wrote:
> On Wednesday, February 4, 2009 2:32 pm Thomas Hellström wrote:
> > Jesse,
> >
> > I have some concerns about the GEM GTT mmap functionality.
>
> Thanks for looking it over again; you would know since some of this code came
> from you in the first place. :)
>
> > First, a gem object pointer is copied to map->offset and then to the
> > vma->vm_private_data without proper reference counting. This pointer is
> > used in i915_gem_fault() to access the gem object. However if the gem
> > object is destroyed and a process then tries to access data in a vma
> > mapping the (now destroyed) object, it would dereference a stale pointer
> > into kernel space? Shouldn't those pointers be reference counted, and to
> > account for fork(), a vm open and close would be needed to reference
> > count corresponding pointers of newly created and destroyed vmas?
>
> Yeah looks like we don't protect against vm_private_data pointing at a freed
> or other object. But rather than refcounting the pointers I wonder if we
> could make the private data use the GEM object name instead, then do the
> lookup in the fault handler?
The object doesn't necessarily have a public name. You do need to
refcount the objects.
--
Eric Anholt
eric@...olt.net eric.anholt@...el.com
Download attachment "signature.asc" of type "application/pgp-signature" (198 bytes)
Powered by blists - more mailing lists