All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dave Jones <davej@redhat.com>
To: Hugh Dickins <hughd@google.com>
Cc: Konstantin Khlebnikov <koct9i@gmail.com>,
	"linux-mm@kvack.org" <linux-mm@kvack.org>,
	Linux Kernel <linux-kernel@vger.kernel.org>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Sasha Levin <sasha.levin@oracle.com>
Subject: Re: 3.15-rc8 mm/filemap.c:202 BUG
Date: Tue, 3 Jun 2014 19:41:11 -0400	[thread overview]
Message-ID: <20140603234111.GA21091@redhat.com> (raw)
In-Reply-To: <alpine.LSU.2.11.1406031524470.7878@eggly.anvils>

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 Schrodinger'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, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

WARNING: multiple messages have this Message-ID (diff)
From: Dave Jones <davej@redhat.com>
To: Hugh Dickins <hughd@google.com>
Cc: Konstantin Khlebnikov <koct9i@gmail.com>,
	"linux-mm@kvack.org" <linux-mm@kvack.org>,
	Linux Kernel <linux-kernel@vger.kernel.org>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Sasha Levin <sasha.levin@oracle.com>
Subject: Re: 3.15-rc8 mm/filemap.c:202 BUG
Date: Tue, 3 Jun 2014 19:41:11 -0400	[thread overview]
Message-ID: <20140603234111.GA21091@redhat.com> (raw)
In-Reply-To: <alpine.LSU.2.11.1406031524470.7878@eggly.anvils>

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


  reply	other threads:[~2014-06-04  0:36 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-06-03  4:21 3.15-rc8 mm/filemap.c:202 BUG Dave Jones
2014-06-03  4:21 ` Dave Jones
2014-06-03  9:11 ` Konstantin Khlebnikov
2014-06-03  9:11   ` Konstantin Khlebnikov
2014-06-03 23:11   ` Hugh Dickins
2014-06-03 23:11     ` Hugh Dickins
2014-06-03 23:41     ` Dave Jones [this message]
2014-06-03 23:41       ` Dave Jones
2014-06-04 12:33     ` Sasha Levin
2014-06-04 12:33       ` Sasha Levin
2014-06-06 23:05       ` Hugh Dickins
2014-06-06 23:05         ` Hugh Dickins
2014-06-06 23:16         ` Linus Torvalds
2014-06-06 23:16           ` Linus Torvalds
2014-06-06 23:21           ` Sasha Levin
2014-06-06 23:21             ` Sasha Levin
  -- strict thread matches above, loose matches on Subject: below --
2014-06-09 12:01 张静(长谷)
2014-06-09 18:52 ` Hugh Dickins

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20140603234111.GA21091@redhat.com \
    --to=davej@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=hughd@google.com \
    --cc=koct9i@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=sasha.levin@oracle.com \
    --cc=torvalds@linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.