All of lore.kernel.org
 help / color / mirror / Atom feed
From: "lixinhai.lxh@gmail.com" <lixinhai.lxh@gmail.com>
To: khlebnikov <khlebnikov@yandex-team.ru>,
	 "linux-mm@kvack.org" <linux-mm@kvack.org>,
	 akpm <akpm@linux-foundation.org>,
	 "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	 richardw.yang <richardw.yang@linux.intel.com>
Cc: "Rik van Riel" <riel@redhat.com>,
	 kirill.shutemov <kirill.shutemov@linux.intel.com>
Subject: Re: [PATCH v2 2/2] kernel/fork: set VMA's mm/prev/next right after vm_area_dup in dup_mmap
Date: Tue, 7 Jan 2020 22:22:09 +0800	[thread overview]
Message-ID: <2020010722220744833867@gmail.com> (raw)
In-Reply-To: 157839239842.694.2288178566540902852.stgit@buzz

On 2020-01-07 at 18:19 Konstantin Khlebnikov wrote:
>Function vm_area_dup() makes exact copy of structure. It's better to stop
>referencing parent structures because various helpers use these pointers.
>
>For example if VM_WIPEONFORK is set then anon_vma_prepare() will try to
>merge anon_vma with previous and next VMA. Poking parent VMAs and sharing
>their anon_vma is safe for now but is not expected behavior.
>
>Note: this will break commit 4e4a9eb92133 ("mm/rmap.c: reuse mergeable
>anon_vma as parent when fork") without related fix because it contains
>several flaws hidden by current initialization sequence in dup_mmap().
>
>Signed-off-by: Konstantin Khlebnikov <khlebnikov@yandex-team.ru> 

looks fine to me.
Reviewed-by: Li Xinhai <lixinhai.lxh@gmail.com>

>---
> kernel/fork.c |    6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
>diff --git a/kernel/fork.c b/kernel/fork.c
>index c33626993831..784c9ae56aa9 100644
>--- a/kernel/fork.c
>+++ b/kernel/fork.c
>@@ -544,10 +544,12 @@ static __latent_entropy int dup_mmap(struct mm_struct *mm,
> tmp = vm_area_dup(mpnt);
> if (!tmp)
> goto fail_nomem;
>+	tmp->vm_mm = mm;
>+	tmp->vm_prev = prev;
>+	tmp->vm_next = NULL;
> retval = vma_dup_policy(mpnt, tmp);
> if (retval)
> goto fail_nomem_policy;
>-	tmp->vm_mm = mm;
> retval = dup_userfaultfd(tmp, &uf);
> if (retval)
> goto fail_nomem_anon_vma_fork;
>@@ -559,7 +561,6 @@ static __latent_entropy int dup_mmap(struct mm_struct *mm,
> } else if (anon_vma_fork(tmp, mpnt, prev))
> goto fail_nomem_anon_vma_fork;
> tmp->vm_flags &= ~(VM_LOCKED | VM_LOCKONFAULT);
>-	tmp->vm_next = tmp->vm_prev = NULL;
> file = tmp->vm_file;
> if (file) {
> struct inode *inode = file_inode(file);
>@@ -592,7 +593,6 @@ static __latent_entropy int dup_mmap(struct mm_struct *mm,
> */
> *pprev = tmp;
> pprev = &tmp->vm_next;
>-	tmp->vm_prev = prev;
> prev = tmp;
>
> __vma_link_rb(mm, tmp, rb_link, rb_parent);
>

  reply	other threads:[~2020-01-07 14:22 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-07 10:19 [PATCH v2 1/2] mm/rmap: fix and simplify reusing mergeable anon_vma as parent when fork Konstantin Khlebnikov
2020-01-07 10:19 ` [PATCH v2 2/2] kernel/fork: set VMA's mm/prev/next right after vm_area_dup in dup_mmap Konstantin Khlebnikov
2020-01-07 14:22   ` lixinhai.lxh [this message]
2020-01-07 13:35 ` [PATCH v2 1/2] mm/rmap: fix and simplify reusing mergeable anon_vma as parent when fork lixinhai.lxh
2020-01-08  2:32 ` Wei Yang
2020-01-08  6:42   ` lixinhai.lxh
2020-01-08 10:40   ` Konstantin Khlebnikov
2020-01-09  2:52     ` Wei Yang
2020-01-09  8:54       ` Konstantin Khlebnikov
2020-01-10  2:30         ` Wei Yang
2020-01-10  3:23           ` Li Xinhai
2020-01-10  5:34             ` Wei Yang
2020-01-10  8:11               ` Konstantin Khlebnikov
2020-01-11 22:38                 ` Wei Yang
2020-01-12  9:55                   ` Konstantin Khlebnikov
2020-01-13  0:33                     ` Wei Yang
2020-01-13 11:07                       ` Konstantin Khlebnikov
2020-01-14  2:09                         ` Wei Yang
2020-01-14 14:42                         ` Li Xinhai
2020-01-15  1:20                           ` Wei Yang
2020-01-18  8:04                             ` Konstantin Khlebnikov
2020-01-18 14:00                               ` Wei Yang

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=2020010722220744833867@gmail.com \
    --to=lixinhai.lxh@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=khlebnikov@yandex-team.ru \
    --cc=kirill.shutemov@linux.intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=richardw.yang@linux.intel.com \
    --cc=riel@redhat.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.