All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dave Jones <davej@redhat.com>
To: Hugh Dickins <hughd@google.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Cong Wang <amwang@redhat.com>,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org
Subject: Re: WARNING: at mm/page-writeback.c:1990 __set_page_dirty_nobuffers+0x13a/0x170()
Date: Fri, 1 Jun 2012 10:09:43 -0400	[thread overview]
Message-ID: <20120601140943.GB1732@redhat.com> (raw)
In-Reply-To: <alpine.LSU.2.00.1206010030050.8462@eggly.anvils>

On Fri, Jun 01, 2012 at 01:44:44AM -0700, Hugh Dickins wrote:

 > > 3f31d07571eeea18a7d34db9af21d2285b807a17 is the first bad commit
 > > commit 3f31d07571eeea18a7d34db9af21d2285b807a17
 > > Author: Hugh Dickins <hughd@google.com>
 > > Date:   Tue May 29 15:06:40 2012 -0700
 > > 
 > >     mm/fs: route MADV_REMOVE to FALLOC_FL_PUNCH_HOLE
 > >     
 > >     Now tmpfs supports hole-punching via fallocate(), switch madvise_remove()
 > >     to use do_fallocate() instead of vmtruncate_range(): which extends
 > >     madvise(,,MADV_REMOVE) support from tmpfs to ext4, ocfs2 and xfs.
 > > 
 > > Hugh ?
 > 
 > Ow, you've caught me.

As I said in another mail, it looks like the bisect was wrong somewhere,
as with this backed out I still see problems.
 
 > One half of the patch at the bottom should fix that: I'm not sure that
 > it's the fix we actually want (a mapping_cap_account_dirty test might
 > be more appropriate, but it's easier just to test a page flag here);
 > but it should be good to shed more light on the problem.

I'll give the patch a try anyway, as builds are quick on that box.

 > So I'm wondering if your trinity fuzzer happens to succeed a lot more
 > often on madvise MADV_REMOVEs than fallocate FALLOC_FL_PUNCH_HOLEs, and
 > the bug you converged on is not in tmpfs, but in ext4 (or xfs? or ocfs2?),
 > which began to support MADV_REMOVE with that commit.

ext4 is a possibility.
 
 > So the second half of the patch should show which filesystem's page is
 > involved when you hit the WARN_ON - unless the first half of the patch
 > turns out to stop the warnings completely, in which case I need to think
 > harder about what was going on in tmpfs, and whether it matters.
 > 
 > Or another possibility is that the bad commit doesn't actually touch mm
 > at all: you were doing a bisection just on mm/ changes, weren't you?

oh, good point. It hadn't occured to me that this could be fs related.
The mm-heavy stack-trace may have misled me.

 > > Sometimes during the bisect these errors happened
 > > in pairs, sometimes only together.
 > 
 > Sometimes in pairs, sometimes together?  I don't understand.

beware late-night emails. I meant sometimes I saw both the list-debug's and the WARN,
but other times I saw only one or the other.

 > Please give this patch a try (preferably on current git), and let us know.
 
Will do.

	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/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
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: Linus Torvalds <torvalds@linux-foundation.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Cong Wang <amwang@redhat.com>,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org
Subject: Re: WARNING: at mm/page-writeback.c:1990 __set_page_dirty_nobuffers+0x13a/0x170()
Date: Fri, 1 Jun 2012 10:09:43 -0400	[thread overview]
Message-ID: <20120601140943.GB1732@redhat.com> (raw)
In-Reply-To: <alpine.LSU.2.00.1206010030050.8462@eggly.anvils>

On Fri, Jun 01, 2012 at 01:44:44AM -0700, Hugh Dickins wrote:

 > > 3f31d07571eeea18a7d34db9af21d2285b807a17 is the first bad commit
 > > commit 3f31d07571eeea18a7d34db9af21d2285b807a17
 > > Author: Hugh Dickins <hughd@google.com>
 > > Date:   Tue May 29 15:06:40 2012 -0700
 > > 
 > >     mm/fs: route MADV_REMOVE to FALLOC_FL_PUNCH_HOLE
 > >     
 > >     Now tmpfs supports hole-punching via fallocate(), switch madvise_remove()
 > >     to use do_fallocate() instead of vmtruncate_range(): which extends
 > >     madvise(,,MADV_REMOVE) support from tmpfs to ext4, ocfs2 and xfs.
 > > 
 > > Hugh ?
 > 
 > Ow, you've caught me.

As I said in another mail, it looks like the bisect was wrong somewhere,
as with this backed out I still see problems.
 
 > One half of the patch at the bottom should fix that: I'm not sure that
 > it's the fix we actually want (a mapping_cap_account_dirty test might
 > be more appropriate, but it's easier just to test a page flag here);
 > but it should be good to shed more light on the problem.

I'll give the patch a try anyway, as builds are quick on that box.

 > So I'm wondering if your trinity fuzzer happens to succeed a lot more
 > often on madvise MADV_REMOVEs than fallocate FALLOC_FL_PUNCH_HOLEs, and
 > the bug you converged on is not in tmpfs, but in ext4 (or xfs? or ocfs2?),
 > which began to support MADV_REMOVE with that commit.

ext4 is a possibility.
 
 > So the second half of the patch should show which filesystem's page is
 > involved when you hit the WARN_ON - unless the first half of the patch
 > turns out to stop the warnings completely, in which case I need to think
 > harder about what was going on in tmpfs, and whether it matters.
 > 
 > Or another possibility is that the bad commit doesn't actually touch mm
 > at all: you were doing a bisection just on mm/ changes, weren't you?

oh, good point. It hadn't occured to me that this could be fs related.
The mm-heavy stack-trace may have misled me.

 > > Sometimes during the bisect these errors happened
 > > in pairs, sometimes only together.
 > 
 > Sometimes in pairs, sometimes together?  I don't understand.

beware late-night emails. I meant sometimes I saw both the list-debug's and the WARN,
but other times I saw only one or the other.

 > Please give this patch a try (preferably on current git), and let us know.
 
Will do.

	Dave

  parent reply	other threads:[~2012-06-01 14:09 UTC|newest]

Thread overview: 87+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-05-30 16:33 WARNING: at mm/page-writeback.c:1990 __set_page_dirty_nobuffers+0x13a/0x170() Dave Jones
2012-05-30 16:33 ` Dave Jones
2012-05-31  0:57 ` Dave Jones
2012-05-31  0:57   ` Dave Jones
2012-06-01  2:31   ` Dave Jones
2012-06-01  2:31     ` Dave Jones
2012-06-01  2:43     ` Linus Torvalds
2012-06-01  2:43       ` Linus Torvalds
2012-06-01 13:43       ` Dave Jones
2012-06-01 13:43         ` Dave Jones
2012-06-01  8:44     ` Hugh Dickins
2012-06-01  8:44       ` Hugh Dickins
2012-06-01  8:51       ` KOSAKI Motohiro
2012-06-01  8:51         ` KOSAKI Motohiro
2012-06-01  9:08         ` Hugh Dickins
2012-06-01  9:08           ` Hugh Dickins
2012-06-01  9:12           ` KOSAKI Motohiro
2012-06-01  9:12             ` KOSAKI Motohiro
2012-06-01 14:09       ` Dave Jones [this message]
2012-06-01 14:09         ` Dave Jones
2012-06-01 14:14       ` Dave Jones
2012-06-01 14:14         ` Dave Jones
2012-06-01 16:12       ` Dave Jones
2012-06-01 16:12         ` Dave Jones
2012-06-01 17:16         ` Dave Jones
2012-06-01 17:16           ` Dave Jones
2012-06-01 22:17           ` Hugh Dickins
2012-06-01 22:17             ` Hugh Dickins
2012-06-02  1:45             ` Linus Torvalds
2012-06-02  1:45               ` Linus Torvalds
2012-06-02  4:40               ` Hugh Dickins
2012-06-02  4:58                 ` Linus Torvalds
2012-06-02  4:58                   ` Linus Torvalds
2012-06-02  7:20                   ` Hugh Dickins
2012-06-02  7:20                     ` Hugh Dickins
2012-06-02  7:17                 ` Markus Trippelsdorf
2012-06-02  7:17                   ` Markus Trippelsdorf
2012-06-02  7:22                   ` Hugh Dickins
2012-06-02  7:22                     ` Hugh Dickins
2012-06-02  7:27                     ` [PATCH] mm: fix warning in __set_page_dirty_nobuffers Hugh Dickins
2012-06-02  7:27                       ` Hugh Dickins
2012-06-03 18:15                 ` WARNING: at mm/page-writeback.c:1990 __set_page_dirty_nobuffers+0x13a/0x170() Dave Jones
2012-06-03 18:15                   ` Dave Jones
2012-06-03 18:23                   ` Linus Torvalds
2012-06-03 18:23                     ` Linus Torvalds
2012-06-03 18:31                     ` Dave Jones
2012-06-03 18:31                       ` Dave Jones
2012-06-03 20:53                       ` Dave Jones
2012-06-03 20:53                         ` Dave Jones
2012-06-03 21:59                         ` Linus Torvalds
2012-06-03 21:59                           ` Linus Torvalds
2012-06-03 22:13                           ` Dave Jones
2012-06-03 22:13                             ` Dave Jones
2012-06-03 22:29                           ` Hugh Dickins
2012-06-03 22:29                             ` Hugh Dickins
2012-06-03 22:17                         ` Hugh Dickins
2012-06-03 22:17                           ` Hugh Dickins
2012-06-03 23:13                           ` Linus Torvalds
2012-06-03 23:13                             ` Linus Torvalds
2012-06-04  0:46                             ` KOSAKI Motohiro
2012-06-04  0:46                               ` KOSAKI Motohiro
2012-06-04  1:18                             ` Hugh Dickins
2012-06-04  1:18                               ` Hugh Dickins
2012-06-04  1:21                             ` Minchan Kim
2012-06-04  1:21                               ` Minchan Kim
2012-06-04  1:26                               ` KOSAKI Motohiro
2012-06-04  1:26                                 ` KOSAKI Motohiro
2012-06-04  2:30                                 ` Minchan Kim
2012-06-04  2:30                                   ` Minchan Kim
2012-06-04  1:10                 ` Minchan Kim
2012-06-04  1:10                   ` Minchan Kim
2012-06-04  1:41                   ` Hugh Dickins
2012-06-04  1:41                     ` Hugh Dickins
2012-06-04  1:47                     ` KOSAKI Motohiro
2012-06-04  1:47                       ` KOSAKI Motohiro
2012-06-04  2:28                     ` Minchan Kim
2012-06-04  2:28                       ` Minchan Kim
2012-06-04  4:21                       ` KOSAKI Motohiro
2012-06-04  4:21                         ` KOSAKI Motohiro
2012-06-04 13:37                       ` Bartlomiej Zolnierkiewicz
2012-06-04 13:37                         ` Bartlomiej Zolnierkiewicz
2012-06-01 16:16       ` Markus Trippelsdorf
2012-06-01 16:16         ` Markus Trippelsdorf
2012-06-01 16:28         ` Linus Torvalds
2012-06-01 16:28           ` Linus Torvalds
2012-06-01 16:39           ` Markus Trippelsdorf
2012-06-01 16:39             ` Markus Trippelsdorf

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=20120601140943.GB1732@redhat.com \
    --to=davej@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=amwang@redhat.com \
    --cc=hughd@google.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --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.