linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Sasha Levin <sasha.levin@oracle.com>
To: Andrew Morton <akpm@linux-foundation.org>,
	Wanpeng Li <liwanp@linux.vnet.ibm.com>
Cc: Hugh Dickins <hughd@google.com>,
	Joonsoo Kim <iamjoonsoo.kim@lge.com>,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org,
	Dave Jones <davej@redhat.com>
Subject: Re: [PATCH] mm/rmap: fix BUG at rmap_walk
Date: Wed, 18 Dec 2013 19:41:44 -0500	[thread overview]
Message-ID: <52B240C8.5070805@oracle.com> (raw)
In-Reply-To: <20131218162858.6ec808c067baf4644532e110@linux-foundation.org>

On 12/18/2013 07:28 PM, Andrew Morton wrote:
> On Thu, 19 Dec 2013 08:16:35 +0800 Wanpeng Li <liwanp@linux.vnet.ibm.com> wrote:
>
>> page_get_anon_vma() called in page_referenced_anon() will lock and
>> increase the refcount of anon_vma, page won't be locked for anonymous
>> page. This patch fix it by skip check anonymous page locked.
>>
>> [  588.698828] kernel BUG at mm/rmap.c:1663!
>
> Why is all this suddenly happening.  Did we change something, or did a
> new test get added to trinity?

Dave has improved mmap testing in trinity, maybe it's related?

> Or if there is no reason why the page must be locked for
> rmap_walk_ksm() and rmap_walk_file(), let's just remove rmap_walk()'s
> VM_BUG_ON()?  And rmap_walk_ksm()'s as well - it's duplicative anyway.

IMO, removing all these VM_BUG_ON()s (which is happening quite often recently) will
lead to having bugs sneak by causing obscure undetected corruption instead of
being very obvious through a BUG.

I know it might be silly, but if we're removing a lot of these - can we "balance"
it back by asking people to introduce new VM_BUG_ON()s, along with a short comment
explaining why to places where these assumptions are going unchecked and are obvious
to them but not to many others?

I'll be more than happy to fuzz through patches that do that to make sure
we catch corner cases.


Thanks,
Sasha

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

  reply	other threads:[~2013-12-19  0:41 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-12-19  0:16 [PATCH] mm/rmap: fix BUG at rmap_walk Wanpeng Li
2013-12-19  0:28 ` Andrew Morton
2013-12-19  0:41   ` Sasha Levin [this message]
2013-12-19  0:50     ` Andrew Morton
2013-12-19  1:30       ` Dave Jones
2013-12-19  0:56   ` Wanpeng Li
2013-12-19  0:58   ` Joonsoo Kim
2013-12-19  1:04     ` Andrew Morton
2013-12-19  1:12       ` Wanpeng Li
2013-12-19  1:14       ` Joonsoo Kim

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=52B240C8.5070805@oracle.com \
    --to=sasha.levin@oracle.com \
    --cc=akpm@linux-foundation.org \
    --cc=davej@redhat.com \
    --cc=hughd@google.com \
    --cc=iamjoonsoo.kim@lge.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=liwanp@linux.vnet.ibm.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).