Re: PROBLEM: kernel BUG at drivers/gpu/drm/drm_fops.c:146!

[Andrew Morton <akpm@linux-foundation.org>]

On Thu, 29 Jan 2009 19:50:17 -0800 Jesse Barnes <jbarnes@virtuousgeek.org> wrote:

> On Thursday, January 29, 2009 5:43 pm Dave Airlie wrote:
> > On Fri, Jan 30, 2009 at 11:20 AM, Andrew Morton
> > > hm, I'm a bit surprised to see the drm code using `struct
> > > address_space' and read_mapping_page() and unmap_mapping_range() and
> > > such.  I thought those only worked with regular files and pagecache :)
> > >
> > > Is it possible to briefly explain what's going on there?
> > >
> > > What instance of address_space_operations does ->dev_mapping actually
> > > point at?
> >
> > Okay a bit tired and headache coming on but I'll try, maybe jbarnes
> > can help out,
> >
> > We need to provide mappings to userspace that are backed by memory
> > that can move around behind the mappings.
> >
> > So userspace wants a mapping for a GEM object via the AGP/GTT aperture
> > instead of directly to the backing pages.
> > Now as the GEM object is backed by shmem we can't use the shmem file
> > descriptor we have to tie the mapping to without
> > hacking up the shmem mmap functionality which seemed like a bad plan.
> >
> > So GEM uses the device inode to setup the mappings on. We just use a
> > simple linear allocator to split up the device inodes address space
> > and assign chunks to handles for different objects. The userspace app
> > then uses the handle via mmap to get access to the VMAs. Now when GEM
> > wants to move that object out of the GTT or to another area of the GTT
> > we need some way to invalidate it, so we use unmap_mapping_range
> > which destroys all the mappings for the object in all the VMA for all
> > the processes mapping it currently
> >
> > GEM's read_mapping_page is distinct from this and is to do with the
> > shmem interfaceing.
> >
> > Not sure if this explains it or just make it worse.
> 
> Sounds right to me.  The offsets are just handles, not real file objects or 
> backing store addresses.  We use them to take advantage of all the inode 
> address mapping helpers, since they track stuff for us.
> 
> That said, unmap_mapping_range may not be the best way to do this; basically 
> we need a way to invalidate a given processes' mapping of a GTT range (which 
> in turn is backed by real RAM).  If there's some other way we should be doing 
> this I'm all ears.

Well, we'd need to call in the big guns on this one - I've already
stirred Hugh ;)

unmap_mapping_range() is basically a truncate thing - it shoots down
all mappings of a range of a *file*.  Across all processes in the
machine which map that file.

If that isn't what you want to do (and it sounds that way) then you'd
want to use something which is mm_struct (or vma) centric, rather than
file-centric.  zap_page_range(), methinks.