From patchwork Mon Jan 6 10:42:40 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Konstantin Khlebnikov X-Patchwork-Id: 11319033 Return-Path: Received: from mail.kernel.org (pdx-korg-mail-1.web.codeaurora.org [172.30.200.123]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id CB85E139A for ; Mon, 6 Jan 2020 10:42:47 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 8DC4B2146E for ; Mon, 6 Jan 2020 10:42:47 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=yandex-team.ru header.i=@yandex-team.ru header.b="S6iDG8Pd" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 8DC4B2146E Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=yandex-team.ru Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id A51848E0005; Mon, 6 Jan 2020 05:42:46 -0500 (EST) Delivered-To: linux-mm-outgoing@kvack.org Received: by kanga.kvack.org (Postfix, from userid 40) id A02CF8E0001; Mon, 6 Jan 2020 05:42:46 -0500 (EST) X-Original-To: int-list-linux-mm@kvack.org X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8F0DD8E0005; Mon, 6 Jan 2020 05:42:46 -0500 (EST) X-Original-To: linux-mm@kvack.org X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0207.hostedemail.com [216.40.44.207]) by kanga.kvack.org (Postfix) with ESMTP id 72BF78E0001 for ; Mon, 6 Jan 2020 05:42:46 -0500 (EST) Received: from smtpin14.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with SMTP id 110C14821 for ; Mon, 6 Jan 2020 10:42:46 +0000 (UTC) X-FDA: 76346871132.14.rub74_3518f00871234 X-Spam-Summary: 2,0,0,aa9b0a034b1ca28b,d41d8cd98f00b204,khlebnikov@yandex-team.ru,::akpm@linux-foundation.org:linux-kernel@vger.kernel.org:richardw.yang@linux.intel.com:kirill.shutemov@linux.intel.com,RULES_HIT:41:69:152:355:379:800:960:973:988:989:1260:1277:1311:1313:1314:1345:1437:1515:1516:1518:1535:1544:1593:1594:1605:1711:1730:1747:1777:1792:1981:2194:2198:2199:2200:2393:2559:2562:2693:2731:2915:3138:3139:3140:3141:3142:3865:3866:3867:3868:3870:3871:3872:3874:4117:4250:4321:5007:6117:6261:6653:7903:9207:9592:10004:11026:11332:11537:11658:11914:12043:12048:12296:12297:12438:12517:12519:12555:12679:12760:12986:14096:14097:14181:14394:14687:14721:14922:21080:21222:21324:21451:21627:21740:21789:30012:30054,0,RBL:95.108.205.193:@yandex-team.ru:.lbl8.mailshell.net-62.2.3.100 66.100.201.201,CacheIP:none,Bayesian:0.5,0.5,0.5,Netcheck:none,DomainCache:0,MSF:not bulk,SPF:fp,MSBL:0,DNSBL:neutral,Custom_rules:0:0:0,LFtime:148,LUA_SUMMARY:none X-HE-Tag: rub74_3518f00871234 X-Filterd-Recvd-Size: 6517 Received: from forwardcorp1o.mail.yandex.net (forwardcorp1o.mail.yandex.net [95.108.205.193]) by imf47.hostedemail.com (Postfix) with ESMTP for ; Mon, 6 Jan 2020 10:42:44 +0000 (UTC) Received: from mxbackcorp2j.mail.yandex.net (mxbackcorp2j.mail.yandex.net [IPv6:2a02:6b8:0:1619::119]) by forwardcorp1o.mail.yandex.net (Yandex) with ESMTP id 47ED62E1430; Mon, 6 Jan 2020 13:42:41 +0300 (MSK) Received: from myt5-70c90f7d6d7d.qloud-c.yandex.net (myt5-70c90f7d6d7d.qloud-c.yandex.net [2a02:6b8:c12:3e2c:0:640:70c9:f7d]) by mxbackcorp2j.mail.yandex.net (mxbackcorp/Yandex) with ESMTP id 2E6fIXUjzS-gePakUEF; Mon, 06 Jan 2020 13:42:41 +0300 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex-team.ru; s=default; t=1578307361; bh=bRVeZsD0ssI2ITrXsE3HS5bNXpMA/dOYQCa6X9aIh44=; h=Message-ID:Date:To:From:Subject:Cc; b=S6iDG8PdFlivCb3idaunrZXUk+s8cjKe00WFd8ruvOMteYgbxUMcvKxRnlwLlCPKL jU7SyUXe7aEgJLKnKqk1uaR3LB0HyOftX67mVpzB8SiQBqjkJYUB8v+rxmDONr4rQD lIdx4c9TkLnzrdKTviHiYQOcxTF6gews81MRLPKg= Authentication-Results: mxbackcorp2j.mail.yandex.net; dkim=pass header.i=@yandex-team.ru Received: from unknown (unknown [2a02:6b8:b080:6708::1:7]) by myt5-70c90f7d6d7d.qloud-c.yandex.net (smtpcorp/Yandex) with ESMTPSA id j38nwkNrq9-geV4IAKt; Mon, 06 Jan 2020 13:42:40 +0300 (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client certificate not present) Subject: [PATCH] mm/rmap: fix reusing mergeable anon_vma as parent when fork From: Konstantin Khlebnikov To: linux-mm@kvack.org, Andrew Morton , linux-kernel@vger.kernel.org, Wei Yang Cc: "Kirill A. Shutemov" Date: Mon, 06 Jan 2020 13:42:40 +0300 Message-ID: <157830736034.8148.7070851958306750616.stgit@buzz> User-Agent: StGit/0.17.1-dirty MIME-Version: 1.0 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: This fixes couple misconceptions in commit 4e4a9eb92133 ("mm/rmap.c: reuse mergeable anon_vma as parent when fork"). First problem caused by initialization order in dup_mmap(): vma->vm_prev is set after calling anon_vma_fork(). Thus in anon_vma_fork() it points to previous VMA in parent mm. This is fixed by rearrangement in dup_mmap(). If in parent VMAs: SRC1 SRC2 .. SRCn share anon-vma ANON0, then after fork before all patches in child process related VMAs: DST1 DST2 .. DSTn will use different anon-vmas: ANON1 ANON2 .. ANONn. Before this patch only DST1 will fork new ANON1 and following DST2 .. DSTn will share parent's ANON0. With this patch DST1 will create new ANON1 and DST2 .. DSTn will share it. Also this patch moves sharing logic out of anon_vma_clone() into more specific anon_vma_fork() because this supposed to work only at fork(). Function anon_vma_clone() is more generic is also used at splitting VMAs. Second problem is hidden behind first one: assumption "Parent has vm_prev, which implies we have vm_prev" is wrong if first VMA in parent mm has set flag VM_DONTCOPY. Luckily prev->anon_vma doesn't dereference NULL pointer because in current code 'prev' actually is same as 'pprev'. To avoid that this patch just checks pointer and compares vm_start to verify relation between previous VMAs in parent and child. Signed-off-by: Konstantin Khlebnikov Fixes: 4e4a9eb92133 ("mm/rmap.c: reuse mergeable anon_vma as parent when fork") Reported-by: Li Xinhai --- kernel/fork.c | 4 ++-- mm/rmap.c | 25 ++++++++++++------------- 2 files changed, 14 insertions(+), 15 deletions(-) diff --git a/kernel/fork.c b/kernel/fork.c index 2508a4f238a3..04ee5e243f65 100644 --- a/kernel/fork.c +++ b/kernel/fork.c @@ -548,6 +548,8 @@ static __latent_entropy int dup_mmap(struct mm_struct *mm, if (retval) goto fail_nomem_policy; tmp->vm_mm = mm; + tmp->vm_prev = prev; /* anon_vma_fork use this */ + tmp->vm_next = NULL; 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)) 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); diff --git a/mm/rmap.c b/mm/rmap.c index b3e381919835..77b3aa38d5c2 100644 --- a/mm/rmap.c +++ b/mm/rmap.c @@ -269,19 +269,6 @@ 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; - struct vm_area_struct *prev = dst->vm_prev, *pprev = src->vm_prev; - - /* - * If parent share anon_vma with its vm_prev, keep this sharing in in - * child. - * - * 1. Parent has vm_prev, which implies we have vm_prev. - * 2. Parent and its vm_prev have the same anon_vma. - */ - if (!dst->anon_vma && src->anon_vma && - pprev && pprev->anon_vma == src->anon_vma) - dst->anon_vma = prev->anon_vma; - list_for_each_entry_reverse(pavc, &src->anon_vma_chain, same_vma) { struct anon_vma *anon_vma; @@ -334,6 +321,7 @@ int anon_vma_clone(struct vm_area_struct *dst, struct vm_area_struct *src) */ int anon_vma_fork(struct vm_area_struct *vma, struct vm_area_struct *pvma) { + struct vm_area_struct *prev = vma->vm_prev, *pprev = pvma->vm_prev; struct anon_vma_chain *avc; struct anon_vma *anon_vma; int error; @@ -345,6 +333,17 @@ int anon_vma_fork(struct vm_area_struct *vma, struct vm_area_struct *pvma) /* Drop inherited anon_vma, we'll reuse existing or allocate new. */ vma->anon_vma = NULL; + /* + * If parent shares anon_vma with its vm_prev, keep this sharing. + * + * Previous VMA could be missing or not match previuos in parent + * if VM_DONTCOPY is set: compare vm_start to avoid this case. + */ + if (pvma->anon_vma && pprev && prev && + pprev->anon_vma == pvma->anon_vma && + pprev->vm_start == prev->vm_start) + vma->anon_vma = prev->anon_vma; + /* * First, attach the new VMA to the parent VMA's anon_vmas, * so rmap can find non-COWed pages in child processes.