[Intel-gfx] memcontrol.c BUG

[Chris Wilson]

On Wed, Jan 28, 2015 at 03:32:43PM +0100, Michal Hocko wrote:
> On Wed 28-01-15 08:48:52, Chris Wilson wrote:
> > On Wed, Jan 28, 2015 at 08:13:06AM +1000, Dave Airlie wrote:
> > > https://bugzilla.redhat.com/show_bug.cgi?id=1165369
> > > 
> > > ov 18 09:23:22 elissa.gathman.org kernel: page:f5e36a40 count:2
> > > mapcount:0 mapping:  (null) index:0x0
> > > Nov 18 09:23:22 elissa.gathman.org kernel: page flags:
> > > 0x80090029(locked|uptodate|lru|swapcache|swapbacked)
> > > Nov 18 09:23:22 elissa.gathman.org kernel: page dumped because:
> > > VM_BUG_ON_PAGE(!lrucare && PageLRU(oldpage))
> > > Nov 18 09:23:23 elissa.gathman.org kernel: ------------[ cut here ]------------
> > > Nov 18 09:23:23 elissa.gathman.org kernel: kernel BUG at mm/memcontrol.c:6733!
> 
> I guess this matches the following bugon in your kernel:
>         VM_BUG_ON_PAGE(!lrucare && PageLRU(oldpage), oldpage);
> 
> so the oldpage is on the LRU list already. I am completely unfamiliar
> with 965GM but is the page perhaps shared with somebody with a different
> gfp mask requirement (e.g. userspace accessing the memory via mmap)? So
> the other (racing) caller didn't need to move the page and put it on
> LRU.

Generally, yes. The shmemfs filp is exported through a vm_mmap() as well
as pinned into the GPU via shmem_read_mapping_page_gfp(). But I would
not expect that to be the case very often, if at all, on 965GM as the
two access paths are incoherent. Still it sounds promising, hopefully
Dave can put it into a fedora kernel for testing?
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre