Re: 3.15-rc8 mm/filemap.c:202 BUG

From: Dave Jones
Date: Tue Jun 03 2014 - 19:41:29 EST


On Tue, Jun 03, 2014 at 04:11:43PM -0700, Hugh Dickins wrote:

> > - BUG_ON(page_mapped(page));
> > + VM_BUG_ON_PAGE(page_mapped(page), page);
> >
> > /*
> > * Some filesystems seem to re-dirty the page even after
>
> Yes, there's a chance that will tell us more (but I don't have high
> hopes of it). I'm still stumped by this issue, just as before.

running with that applied now.

> Sasha (or Dave), any update on whether you see this without THP?
> and whether you see the remove_migration_pte oops without THP?

haven't tried yet. I wish I had a better reproducer, because it can
take up to a day to show up, and if disabling THP makes it go away,
it's hard to judge if that's the case, or if I haven't been running
long enough.. Sort of a Schrödinger's BUG_ON.

After I get a trace with the above patch applied, I'll give it a shot
though, just to see what happens.

> Mind you, I've probably given too little weight to the fact that every
> stacktrace shown has been a shmem one: originally I assumed that just
> reflected trinity running its tests on a tmpfs, now I wonder: Dave,
> Sasha, are you running similar tests on tmpfs and other filesystems,
> and find this only in the tmpfs case?

In my case, there's a tmpfs mounted, but it's extremely unlikely that
trinity walked into it. Perhaps I should try that, to see if it happens
faster.


> > I don't like the way in which truncate silently skips page entries
> > when they are changing under it.
> > Completely untested patch follows.
> >
> > --- a/mm/shmem.c
> > +++ b/mm/shmem.c
> > @@ -495,8 +495,9 @@ static void shmem_undo_range(struct inode *inode,
> > loff_t lstart, loff_t lend,
> > if (radix_tree_exceptional_entry(page)) {
> > if (unfalloc)
> > continue;
> > - nr_swaps_freed += !shmem_free_swap(mapping,
> > - index, page);
> > + if (shmem_free_swap(mapping, index, page))
> > + goto retry;
> > + nr_swaps_freed++;
> > continue;
> > }
> >
> > @@ -509,10 +510,11 @@ static void shmem_undo_range(struct inode
> > *inode, loff_t lstart, loff_t lend,
> > }
> > unlock_page(page);
> > }
> > + index++;
> > +retry:
> > pagevec_remove_exceptionals(&pvec);
> > pagevec_release(&pvec);
> > mem_cgroup_uncharge_end();
> > - index++;
> > }

I'll add this to the queue of things to test, but that queue is now
about two days deep already :)

Dave

--
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/