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

[Jesse Barnes]

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.

-- 
Jesse Barnes, Intel Open Source Technology Center
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/