[Intel-gfx] memcontrol.c BUG

[Dave Airlie]

On 29 January 2015 at 18:16, Chris Wilson <chris at chris-wilson.co.uk> wrote:
> 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?

http://kojipkgs.fedoraproject.org/scratch/airlied/task_8760024/

done, also asked on the bug for testers.

Dave.