[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20140603234111.GA21091@redhat.com>
Date: Tue, 3 Jun 2014 19:41:11 -0400
From: Dave Jones <davej@...hat.com>
To: Hugh Dickins <hughd@...gle.com>
Cc: Konstantin Khlebnikov <koct9i@...il.com>,
"linux-mm@...ck.org" <linux-mm@...ck.org>,
Linux Kernel <linux-kernel@...r.kernel.org>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Andrew Morton <akpm@...ux-foundation.org>,
Sasha Levin <sasha.levin@...cle.com>
Subject: Re: 3.15-rc8 mm/filemap.c:202 BUG
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@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists