From: Nai Xia <nai.xia@gmail.com>
To: Hugh Dickins <hughd@google.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
Andrew Morton <akpm@linux-foundation.org>,
Shaohua Li <shaohua.li@intel.com>,
linux-kernel@vger.kernel.org, linux-mm@kvack.org
Subject: Re: [PATCH] mm: fix kernel BUG at mm/rmap.c:1017!
Date: Sun, 29 May 2011 18:23:46 +0800 [thread overview]
Message-ID: <201105291823.47082.nai.xia@gmail.com> (raw)
In-Reply-To: <alpine.LSU.2.00.1105281314220.13319@sister.anvils>
On Sunday 29 May 2011 04:17:04 Hugh Dickins wrote:
> I've hit the "address >= vma->vm_end" check in do_page_add_anon_rmap()
> just once. The stack showed khugepaged allocation trying to compact
> pages: the call to page_add_anon_rmap() coming from remove_migration_pte().
>
> That path holds anon_vma lock, but does not hold mmap_sem: it can
> therefore race with a split_vma(), and in commit 5f70b962ccc2 "mmap:
> avoid unnecessary anon_vma lock" we just took away the anon_vma lock
> protection when adjusting vma->vm_end.
>
> I don't think that particular BUG_ON ever caught anything interesting,
> so better replace it by a comment, than reinstate the anon_vma locking.
Is there another racing between "vma->vm_pgoff = pgoff;" in
vma_adjust() and linear_page_index() in __page_set_anon_rmap() ?
Nai Xia
>
> Signed-off-by: Hugh Dickins <hughd@google.com>
> ---
> mm/rmap.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> --- linux.orig/mm/rmap.c 2011-05-27 19:05:27.000000000 -0700
> +++ linux/mm/rmap.c 2011-05-27 20:07:44.601361236 -0700
> @@ -1014,7 +1014,7 @@ void do_page_add_anon_rmap(struct page *
> return;
>
> VM_BUG_ON(!PageLocked(page));
> - VM_BUG_ON(address < vma->vm_start || address >= vma->vm_end);
> + /* address might be in next vma when migration races vma_adjust */
> if (first)
> __page_set_anon_rmap(page, vma, address, exclusive);
> else
> @@ -1709,7 +1709,7 @@ void hugepage_add_anon_rmap(struct page
>
> BUG_ON(!PageLocked(page));
> BUG_ON(!anon_vma);
> - BUG_ON(address < vma->vm_start || address >= vma->vm_end);
> + /* address might be in next vma when migration races vma_adjust */
> first = atomic_inc_and_test(&page->_mapcount);
> if (first)
> __hugepage_set_anon_rmap(page, vma, address, 0);
>
> --
> 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: Nai Xia <nai.xia@gmail.com>
To: Hugh Dickins <hughd@google.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
Andrew Morton <akpm@linux-foundation.org>,
Shaohua Li <shaohua.li@intel.com>,
linux-kernel@vger.kernel.org, linux-mm@kvack.org
Subject: Re: [PATCH] mm: fix kernel BUG at mm/rmap.c:1017!
Date: Sun, 29 May 2011 18:23:46 +0800 [thread overview]
Message-ID: <201105291823.47082.nai.xia@gmail.com> (raw)
In-Reply-To: <alpine.LSU.2.00.1105281314220.13319@sister.anvils>
On Sunday 29 May 2011 04:17:04 Hugh Dickins wrote:
> I've hit the "address >= vma->vm_end" check in do_page_add_anon_rmap()
> just once. The stack showed khugepaged allocation trying to compact
> pages: the call to page_add_anon_rmap() coming from remove_migration_pte().
>
> That path holds anon_vma lock, but does not hold mmap_sem: it can
> therefore race with a split_vma(), and in commit 5f70b962ccc2 "mmap:
> avoid unnecessary anon_vma lock" we just took away the anon_vma lock
> protection when adjusting vma->vm_end.
>
> I don't think that particular BUG_ON ever caught anything interesting,
> so better replace it by a comment, than reinstate the anon_vma locking.
Is there another racing between "vma->vm_pgoff = pgoff;" in
vma_adjust() and linear_page_index() in __page_set_anon_rmap() ?
Nai Xia
>
> Signed-off-by: Hugh Dickins <hughd@google.com>
> ---
> mm/rmap.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> --- linux.orig/mm/rmap.c 2011-05-27 19:05:27.000000000 -0700
> +++ linux/mm/rmap.c 2011-05-27 20:07:44.601361236 -0700
> @@ -1014,7 +1014,7 @@ void do_page_add_anon_rmap(struct page *
> return;
>
> VM_BUG_ON(!PageLocked(page));
> - VM_BUG_ON(address < vma->vm_start || address >= vma->vm_end);
> + /* address might be in next vma when migration races vma_adjust */
> if (first)
> __page_set_anon_rmap(page, vma, address, exclusive);
> else
> @@ -1709,7 +1709,7 @@ void hugepage_add_anon_rmap(struct page
>
> BUG_ON(!PageLocked(page));
> BUG_ON(!anon_vma);
> - BUG_ON(address < vma->vm_start || address >= vma->vm_end);
> + /* address might be in next vma when migration races vma_adjust */
> first = atomic_inc_and_test(&page->_mapcount);
> if (first)
> __hugepage_set_anon_rmap(page, vma, address, 0);
>
> --
> 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>
>
--
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>
next prev parent reply other threads:[~2011-05-29 10:24 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-05-28 20:17 [PATCH] mm: fix kernel BUG at mm/rmap.c:1017! Hugh Dickins
2011-05-28 20:17 ` Hugh Dickins
2011-05-29 10:23 ` Nai Xia [this message]
2011-05-29 10:23 ` Nai Xia
2011-05-29 12:16 ` Nai Xia
2011-05-29 12:16 ` Nai Xia
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=201105291823.47082.nai.xia@gmail.com \
--to=nai.xia@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=hughd@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=shaohua.li@intel.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.