All of lore.kernel.org
 help / color / mirror / Atom feed
From: Wei Yang <richardw.yang@linux.intel.com>
To: Wei Yang <richardw.yang@linux.intel.com>
Cc: akpm@linux-foundation.org, kirill.shutemov@linux.intel.com,
	jglisse@redhat.com, mike.kravetz@oracle.com, riel@surriel.com,
	khlebnikov@yandex-team.ru, cai@lca.pw, shakeelb@google.com,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [Patch v3 1/2] mm/rmap.c: don't reuse anon_vma if we just want a copy
Date: Fri, 11 Oct 2019 13:21:07 +0800	[thread overview]
Message-ID: <20191011052107.GA22714@richard> (raw)
In-Reply-To: <20191011025841.16801-1-richardw.yang@linux.intel.com>

On Fri, Oct 11, 2019 at 10:58:40AM +0800, Wei Yang wrote:
>Before commit 7a3ef208e662 ("mm: prevent endless growth of anon_vma
>hierarchy"), anon_vma_clone() doesn't change dst->anon_vma. While after
>this commit, anon_vma_clone() will try to reuse an exist one on forking.
>
>But this commit go a little bit further for the case not forking.
>anon_vma_clone() is called from __vma_split(), __split_vma(), copy_vma()
>and anon_vma_fork(). For the first three places, the purpose here is get
>a copy of src and we don't expect to touch dst->anon_vma even it is
>NULL. While after that commit, it is possible to reuse an anon_vma when
>dst->anon_vma is NULL. This is not we intend to have.
>
>This patch stop reuse anon_vma for non-fork cases.
>
>Fix commit 7a3ef208e662 ("mm: prevent endless growth of anon_vma
>hierarchy")
>
>Signed-off-by: Wei Yang <richardw.yang@linux.intel.com>
>
>---
>v3:
>  * use dst->anon_vma and src->anon_vma to get reuse state
>    pointed by Konstantin Khlebnikov
>---
> mm/rmap.c | 12 +++++++++---
> 1 file changed, 9 insertions(+), 3 deletions(-)
>
>diff --git a/mm/rmap.c b/mm/rmap.c
>index d9a23bb773bf..fc0aba7fb9b9 100644
>--- a/mm/rmap.c
>+++ b/mm/rmap.c
>@@ -250,7 +250,13 @@ static inline void unlock_anon_vma_root(struct anon_vma *root)
>  * Attach the anon_vmas from src to dst.
>  * Returns 0 on success, -ENOMEM on failure.
>  *
>- * If dst->anon_vma is NULL this function tries to find and reuse existing
>+ * anon_vma_clone() is called by __vma_split(), __split_vma(), copy_vma() and
>+ * anon_vma_fork(). The first three want an exact copy of src, while the last
>+ * one, anon_vma_fork(), may try to reuse an existing anon_vma to prevent
>+ * endless growth of anon_vma. Since dst->anon_vma is set to NULL before call,
>+ * we can identify this case by (reuse = !dst->anon_vma && src->anon_vma).
>+ *
>+ * If reuse is true, this function tries to find and reuse existing
>  * anon_vma which has no vmas and only one child anon_vma. This prevents
>  * degradation of anon_vma hierarchy to endless linear chain in case of
>  * constantly forking task. On the other hand, an anon_vma with more than one
>@@ -262,6 +268,7 @@ int anon_vma_clone(struct vm_area_struct *dst, struct vm_area_struct *src)
> {
> 	struct anon_vma_chain *avc, *pavc;
> 	struct anon_vma *root = NULL;
>+	bool reuse = !dst->anon_vma && src->anon_vma;
> 
> 	list_for_each_entry_reverse(pavc, &src->anon_vma_chain, same_vma) {
> 		struct anon_vma *anon_vma;
>@@ -286,8 +293,7 @@ int anon_vma_clone(struct vm_area_struct *dst, struct vm_area_struct *src)
> 		 * will always reuse it. Root anon_vma is never reused:
> 		 * it has self-parent reference and at least one child.
> 		 */
>-		if (!dst->anon_vma && anon_vma != src->anon_vma &&
>-				anon_vma->degree < 2)
>+		if (reuse && anon_vma != src->anon_vma && anon_vma->degree < 2)
> 			dst->anon_vma = anon_vma;

What a shame.

dst->anon_vma would be changed in the loop, so we only need to assign it when
dst->anon_vma == NULL.

> 	}
> 	if (dst->anon_vma)
>-- 
>2.17.1

-- 
Wei Yang
Help you, Help me


      parent reply	other threads:[~2019-10-11  5:21 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-11  2:58 [Patch v3 1/2] mm/rmap.c: don't reuse anon_vma if we just want a copy Wei Yang
2019-10-11  2:58 ` [Patch v3 2/2] mm/rmap.c: reuse mergeable anon_vma as parent when fork Wei Yang
2019-10-11  5:21 ` Wei Yang [this message]

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=20191011052107.GA22714@richard \
    --to=richardw.yang@linux.intel.com \
    --cc=akpm@linux-foundation.org \
    --cc=cai@lca.pw \
    --cc=jglisse@redhat.com \
    --cc=khlebnikov@yandex-team.ru \
    --cc=kirill.shutemov@linux.intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mike.kravetz@oracle.com \
    --cc=riel@surriel.com \
    --cc=shakeelb@google.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 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.