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

[Jesse Barnes <jbarnes@virtuousgeek.org>]

On Friday, January 30, 2009 1:21 am Andrew Morton wrote:
> On Fri, 30 Jan 2009 10:13:55 +0100 Thomas Hellstr__m <thomas@shipmail.org> 
wrote:
> > >> 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.
> >
> > I guess I was the one starting to use this function, so some explanation:
> >
> > When the drm device is used to provide address space for buffers,
> > user-space actually see it as a file with a distinct offset where
> > buffers are laid out in a linear fashion, To access a certain buffer you
> > need to lseek() to the correct offset and then read() write() or, the
> > more common use, mmap / munmap.
> >
> > When looking through its implementation, unmap_mapping_range() seemed to
> > do exactly the thing I wanted, namely to kill all user-space mappings of
> > all vmas of all processes mapping a part of the device address space.
>
> That's different from what Jesse said.  That _is_ a more appropriate
> use of unmap_mapping_range().  Although all the futzing that function
> does with truncate_count is now looking inappropriately-placed.

Yeah I misspoke, we do need to blow away *all* the mappings, not just the ones 
for a given process (since the backing GTT mapping is gone/moved).  We could 
probably use zap_page_range, but might have to do a bit more work in the 
driver if we did.

-- 
Jesse Barnes, Intel Open Source Technology Center