From: Rik van Riel <riel@redhat.com>
To: Leon Yu <chianglungyu@gmail.com>,
Andrew Morton <akpm@linux-foundation.org>,
Konstantin Khlebnikov <koct9i@gmail.com>,
Michal Hocko <mhocko@suse.cz>
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org,
Vlastimil Babka <vbabka@suse.cz>,
Daniel Forrest <dan.forrest@ssec.wisc.edu>,
Chris Clayton <chris2553@googlemail.com>,
Oded Gabbay <oded.gabbay@amd.com>,
Chih-Wei Huang <cwhuang@android-x86.org>,
stable@vger.kernel.org
Subject: Re: [PATCH v2] mm: fix anon_vma->degree underflow in anon_vma endless growing prevention
Date: Wed, 04 Mar 2015 12:58:38 -0500 [thread overview]
Message-ID: <54F747CE.5050204@redhat.com> (raw)
In-Reply-To: <1425473541-4924-1-git-send-email-chianglungyu@gmail.com>
On 03/04/2015 07:52 AM, Leon Yu wrote:
> I have constantly stumbled upon "kernel BUG at mm/rmap.c:399!" after
> upgrading to 3.19 and had no luck with 4.0-rc1 neither.
>
> So, after looking into new logic introduced by 7a3ef208e662 ("mm: prevent
> endless growth of anon_vma hierarchy"), I found chances are that
> unlink_anon_vmas() is called without incrementing dst->anon_vma->degree in
> anon_vma_clone() due to allocation failure. If dst->anon_vma is not NULL
> in error path, its degree will be incorrectly decremented in
> unlink_anon_vmas() and eventually underflow when exiting as a result of
> another call to unlink_anon_vmas(). That's how "kernel BUG at
> mm/rmap.c:399!" is triggered for me.
>
> This patch fixes the underflow by dropping dst->anon_vma when allocation
> fails. It's safe to do so regardless of original value of dst->anon_vma
> because dst->anon_vma doesn't have valid meaning if anon_vma_clone()
> fails. Besides, callers don't care dst->anon_vma in such case neither.
>
> Also suggested by Michal Hocko, we can clean up vma_adjust() a bit as
> anon_vma_clone() now does the work.
>
> Fixes: 7a3ef208e662 ("mm: prevent endless growth of anon_vma hierarchy")
> Signed-off-by: Leon Yu <chianglungyu@gmail.com>
> Signed-off-by: Konstantin Khlebnikov <koct9i@gmail.com>
> Reviewed-by: Michal Hocko <mhocko@suse.cz>
> Acked-by: David Rientjes <rientjes@google.com>
> Cc: <stable@vger.kernel.org>
Acked-by: Rik van Riel <riel@redhat.com>
--
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: Rik van Riel <riel@redhat.com>
To: Leon Yu <chianglungyu@gmail.com>,
Andrew Morton <akpm@linux-foundation.org>,
Konstantin Khlebnikov <koct9i@gmail.com>,
Michal Hocko <mhocko@suse.cz>
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org,
Vlastimil Babka <vbabka@suse.cz>,
Daniel Forrest <dan.forrest@ssec.wisc.edu>,
Chris Clayton <chris2553@googlemail.com>,
Oded Gabbay <oded.gabbay@amd.com>,
Chih-Wei Huang <cwhuang@android-x86.org>,
stable@vger.kernel.org
Subject: Re: [PATCH v2] mm: fix anon_vma->degree underflow in anon_vma endless growing prevention
Date: Wed, 04 Mar 2015 12:58:38 -0500 [thread overview]
Message-ID: <54F747CE.5050204@redhat.com> (raw)
In-Reply-To: <1425473541-4924-1-git-send-email-chianglungyu@gmail.com>
On 03/04/2015 07:52 AM, Leon Yu wrote:
> I have constantly stumbled upon "kernel BUG at mm/rmap.c:399!" after
> upgrading to 3.19 and had no luck with 4.0-rc1 neither.
>
> So, after looking into new logic introduced by 7a3ef208e662 ("mm: prevent
> endless growth of anon_vma hierarchy"), I found chances are that
> unlink_anon_vmas() is called without incrementing dst->anon_vma->degree in
> anon_vma_clone() due to allocation failure. If dst->anon_vma is not NULL
> in error path, its degree will be incorrectly decremented in
> unlink_anon_vmas() and eventually underflow when exiting as a result of
> another call to unlink_anon_vmas(). That's how "kernel BUG at
> mm/rmap.c:399!" is triggered for me.
>
> This patch fixes the underflow by dropping dst->anon_vma when allocation
> fails. It's safe to do so regardless of original value of dst->anon_vma
> because dst->anon_vma doesn't have valid meaning if anon_vma_clone()
> fails. Besides, callers don't care dst->anon_vma in such case neither.
>
> Also suggested by Michal Hocko, we can clean up vma_adjust() a bit as
> anon_vma_clone() now does the work.
>
> Fixes: 7a3ef208e662 ("mm: prevent endless growth of anon_vma hierarchy")
> Signed-off-by: Leon Yu <chianglungyu@gmail.com>
> Signed-off-by: Konstantin Khlebnikov <koct9i@gmail.com>
> Reviewed-by: Michal Hocko <mhocko@suse.cz>
> Acked-by: David Rientjes <rientjes@google.com>
> Cc: <stable@vger.kernel.org>
Acked-by: Rik van Riel <riel@redhat.com>
next prev parent reply other threads:[~2015-03-04 17:58 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-03-04 12:52 [PATCH v2] mm: fix anon_vma->degree underflow in anon_vma endless growing prevention Leon Yu
2015-03-04 12:52 ` Leon Yu
2015-03-04 12:52 ` Leon Yu
2015-03-04 17:58 ` Rik van Riel [this message]
2015-03-04 17:58 ` Rik van Riel
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=54F747CE.5050204@redhat.com \
--to=riel@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=chianglungyu@gmail.com \
--cc=chris2553@googlemail.com \
--cc=cwhuang@android-x86.org \
--cc=dan.forrest@ssec.wisc.edu \
--cc=koct9i@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@suse.cz \
--cc=oded.gabbay@amd.com \
--cc=stable@vger.kernel.org \
--cc=vbabka@suse.cz \
/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.