From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 4740BCE7B1F for ; Fri, 29 Sep 2023 10:07:59 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id ABF506B00B5; Fri, 29 Sep 2023 06:07:58 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id A6F966B00BB; Fri, 29 Sep 2023 06:07:58 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8E8CC6B00C5; Fri, 29 Sep 2023 06:07:58 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 79FB16B00B5 for ; Fri, 29 Sep 2023 06:07:58 -0400 (EDT) Received: from smtpin20.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 3DF9D1A0C96 for ; Fri, 29 Sep 2023 10:07:58 +0000 (UTC) X-FDA: 81289209036.20.3808AE5 Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.220.29]) by imf23.hostedemail.com (Postfix) with ESMTP id 0C2AB14000D for ; Fri, 29 Sep 2023 10:07:55 +0000 (UTC) Authentication-Results: imf23.hostedemail.com; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=jgC4hodI; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=quDPbF5K; spf=pass (imf23.hostedemail.com: domain of vbabka@suse.cz designates 195.135.220.29 as permitted sender) smtp.mailfrom=vbabka@suse.cz; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1695982076; a=rsa-sha256; cv=none; b=plAZifW48gEYIpu83IXnRoa1UQNix2RacmPSrqB2gxrdDkTWVQO/4sT/cmzCkHsLt18YqU hzOfW/abLi8YyWwFo19U5EHZm7h8X6breIrBCLKbchiyA0J224T6i2IklUNQfZflTJs44F 1rWtOoX0ZgJKeRZotvIwZlTZOBxiHs8= ARC-Authentication-Results: i=1; imf23.hostedemail.com; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=jgC4hodI; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=quDPbF5K; spf=pass (imf23.hostedemail.com: domain of vbabka@suse.cz designates 195.135.220.29 as permitted sender) smtp.mailfrom=vbabka@suse.cz; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1695982076; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=uP27RjshjL1KIEOKtQj2rsOmdqwjCeXDZ2XS9nnjPxk=; b=oECbYNvJjamH8SF/voD+yMAxfkbLOFvMg6qPGqG3PpOz82ReVTZf3ML/PnNDJEKwoRyLmQ u++mk4qNfPo7rulHcMstzqIkA38k3W6GBq7g5oWKOZgvwtoOdfGYBz0na53cvBP6NVHoGj tEDcywk1STyPv3/zlTkmKqu2BaD0MrM= Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by smtp-out2.suse.de (Postfix) with ESMTPS id 385091F390; Fri, 29 Sep 2023 10:07:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1695982074; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=uP27RjshjL1KIEOKtQj2rsOmdqwjCeXDZ2XS9nnjPxk=; b=jgC4hodI36kBtyUgQ90FUnGcpwVkK+BYwH3LsdSL3wTjWCN4U0gN0fHoWpwjUuiwE8rcCN B7aQAnIn2MzJZZyMvrGiYLLSMbtQCGi4lLZCeEredW+cfLz9MmBkcQmiMCrgCZ7idj7ADn wkrtJbsl1rsi1aQeb4i1wo5cwMLac0I= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1695982074; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=uP27RjshjL1KIEOKtQj2rsOmdqwjCeXDZ2XS9nnjPxk=; b=quDPbF5KwxD1lPn4oS1Y0e6lyTlb4+GsLzJQXWhcybTZ8V+JiKd++t2An1D55TPYKezVX3 TJulFFAUnydJkaAQ== Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by imap2.suse-dmz.suse.de (Postfix) with ESMTPS id 119B31390A; Fri, 29 Sep 2023 10:07:54 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id iVZ9A/qhFmWKHQAAMHmgww (envelope-from ); Fri, 29 Sep 2023 10:07:54 +0000 Message-ID: <437896e6-c54e-4c5a-f1af-46d91ea6f155@suse.cz> Date: Fri, 29 Sep 2023 12:07:53 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.15.1 Subject: Re: [PATCH 2/3] mmap: Fix error paths with dup_anon_vma() Content-Language: en-US To: "Liam R. Howlett" , Andrew Morton Cc: maple-tree@lists.infradead.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, Jann Horn , Lorenzo Stoakes , Suren Baghdasaryan , Matthew Wilcox , stable@vger.kernel.org References: <20230927160746.1928098-1-Liam.Howlett@oracle.com> <20230927160746.1928098-3-Liam.Howlett@oracle.com> From: Vlastimil Babka In-Reply-To: <20230927160746.1928098-3-Liam.Howlett@oracle.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Rspamd-Server: rspam08 X-Rspamd-Queue-Id: 0C2AB14000D X-Stat-Signature: ckttanop53hsemzu374yczetz8tyii4o X-Rspam-User: X-HE-Tag: 1695982075-244793 X-HE-Meta: U2FsdGVkX1+DQ7Mnv7hnq9ce5ymSTyye69z+R2n5Z/pJxEcrrDDrGDg4qX/LVm05lj0o7IMTQselqVRmAN1iuWonSRx7Od0MNeXkhbvuGJIp1+Tkhk+cmk4mKu1pbYDnSjDz9Nrs6pbTqQivqk9akyCnmjn4bTUofTssmpwJv8KN9gNFIoCqImS5+Kf0MRXIlgz11pKtpNlPuuQZJOxR+Mm/uiVKITA3HN9/6Ko/hsQ2zoh9ah6UTQ0e1BL5njeHdDM1rcHl2athPW49qUi2SLsgG8aRt/OAiRmnyS4/5GtVqhhvkzUxDWMbwDUiDqrs2YWTamtKXF4X/uIvCi8WA7X5R4BJM0j66/wHcEMd907707fiM/sunMopNcPblXBi9JnRWT049x4XR0YAwS4nDkj6e7ouNzFpz4OTxWGj9cANmLbyNPpd+4VlwI+/HU3WOi3SoSlmyuvD9rKsl6UGFFFr+iKjkSMTIN+mE5CAOezkhkOK++XaUD3a3QQnW/61gBo7QOuQzkOb/hFFvVTjqBb+WNGxVV8j5V9tW2n7b6b7sU2l8jiYUZwu5cpDGvTUf+yMBK78ZDbiM5Z57O8DhNUamjedkz4UbMLtAEnpYmIceNZXw60ZNyAPYg20d7iEi5TF35oWgVkstDp/JWpEsiHq8p512pn26eY03cp1XpJX2AZJ3kcJPaAFI0PQlP6UHhKy1B0QU2bdP68jt9Eb0C3/IW5LEZmC2k0AxgUinSj8cRYJWKLmfBZWEA8Md98x6pknxOugeOfHkaCUpHC8Ox+KMygZ+vNKOOmiDw2biSfAAyZhs1Syx+kgwqH0aHu8opLv+hwWAcvRxLd0QBIG+515qNQFnhk7JvenWtlcgMrfkH0aUSVWe73+se5irSRCYe5Q+FJSIdhQAr6AKpTll4mERaOSIzEEXIiAPtOl+db76m5LK67cC1/vQpYMLz64VjnYraLEAjDu2goE70c 6vlyJnl8 qfXJD9mYng0/c9/Hhxfg91nH5xNCloFoYglLEKDGPxq93wE4OdXFcmyWkIx3PlEm7iuQ5r0gc3AIQMrLdRoV7N0lFz1sVOK/l91YFNOwDfa7GKUICf7YkDJlp/kJ5UL5VghHd7ehTan9iaARJ3Ya/vyp8V0ASZbKMs1jzxZLoPLMB9LnJn67qLK3OtazsVHX6PqQNBEIT7GqBE/YkBY8L+XqjuoFbqM3tTuqqFHhfCagsnimUE4yv/1IQkDBgtqnJLZDAgi2Km8maN/sEQKskDLiyNP2ldKODSrt5RCOiWO+3a5q6YntwK0ojVW+aNXR+NPZZZ52o76A/ccIt7se6fQ0jeoQQgCJaHop3 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: On 9/27/23 18:07, Liam R. Howlett wrote: > When the calling function fails after the dup_anon_vma(), the > duplication of the anon_vma is not being undone. Add the necessary > unlink_anon_vma() call to the error paths that are missing them. > > This issue showed up during inspection of the error path in vma_merge() > for an unrelated vma iterator issue. > > Users may experience increased memory usage, which may be problematic as > the failure would likely be caused by a low memory situation. > > Fixes: d4af56c5c7c6 ("mm: start tracking VMAs with maple tree") > Cc: stable@vger.kernel.org > Cc: Jann Horn > Signed-off-by: Liam R. Howlett > --- > mm/mmap.c | 20 ++++++++++++++------ > 1 file changed, 14 insertions(+), 6 deletions(-) > > diff --git a/mm/mmap.c b/mm/mmap.c > index b5bc4ca9bdc4..2f0ee489db8a 100644 > --- a/mm/mmap.c > +++ b/mm/mmap.c > @@ -587,7 +587,7 @@ static inline void vma_complete(struct vma_prepare *vp, > * Returns: 0 on success. > */ > static inline int dup_anon_vma(struct vm_area_struct *dst, > - struct vm_area_struct *src) > + struct vm_area_struct *src, struct vm_area_struct **dup) > { > /* > * Easily overlooked: when mprotect shifts the boundary, make sure the > @@ -597,6 +597,7 @@ static inline int dup_anon_vma(struct vm_area_struct *dst, > if (src->anon_vma && !dst->anon_vma) { > vma_assert_write_locked(dst); > dst->anon_vma = src->anon_vma; > + *dup = dst; > return anon_vma_clone(dst, src); So the code is simpler that way and seems current callers are fine, but shouldn't we rather only assign *dup if the clone succeeds? > } > > @@ -624,6 +625,7 @@ int vma_expand(struct vma_iterator *vmi, struct vm_area_struct *vma, > unsigned long start, unsigned long end, pgoff_t pgoff, > struct vm_area_struct *next) > { > + struct vm_area_struct *anon_dup = NULL; > bool remove_next = false; > struct vma_prepare vp; > > @@ -633,7 +635,7 @@ int vma_expand(struct vma_iterator *vmi, struct vm_area_struct *vma, > > remove_next = true; > vma_start_write(next); > - ret = dup_anon_vma(vma, next); > + ret = dup_anon_vma(vma, next, &anon_dup); > if (ret) > return ret; > } > @@ -661,6 +663,8 @@ int vma_expand(struct vma_iterator *vmi, struct vm_area_struct *vma, > return 0; > > nomem: > + if (anon_dup) > + unlink_anon_vmas(anon_dup); > return -ENOMEM; > } > > @@ -860,6 +864,7 @@ struct vm_area_struct *vma_merge(struct vma_iterator *vmi, struct mm_struct *mm, > { > struct vm_area_struct *curr, *next, *res; > struct vm_area_struct *vma, *adjust, *remove, *remove2; > + struct vm_area_struct *anon_dup = NULL; > struct vma_prepare vp; > pgoff_t vma_pgoff; > int err = 0; > @@ -927,18 +932,18 @@ struct vm_area_struct *vma_merge(struct vma_iterator *vmi, struct mm_struct *mm, > vma_start_write(next); > remove = next; /* case 1 */ > vma_end = next->vm_end; > - err = dup_anon_vma(prev, next); > + err = dup_anon_vma(prev, next, &anon_dup); > if (curr) { /* case 6 */ > vma_start_write(curr); > remove = curr; > remove2 = next; > if (!next->anon_vma) > - err = dup_anon_vma(prev, curr); > + err = dup_anon_vma(prev, curr, &anon_dup); > } > } else if (merge_prev) { /* case 2 */ > if (curr) { > vma_start_write(curr); > - err = dup_anon_vma(prev, curr); > + err = dup_anon_vma(prev, curr, &anon_dup); > if (end == curr->vm_end) { /* case 7 */ > remove = curr; > } else { /* case 5 */ > @@ -954,7 +959,7 @@ struct vm_area_struct *vma_merge(struct vma_iterator *vmi, struct mm_struct *mm, > vma_end = addr; > adjust = next; > adj_start = -(prev->vm_end - addr); > - err = dup_anon_vma(next, prev); > + err = dup_anon_vma(next, prev, &anon_dup); > } else { > /* > * Note that cases 3 and 8 are the ONLY ones where prev > @@ -1018,6 +1023,9 @@ struct vm_area_struct *vma_merge(struct vma_iterator *vmi, struct mm_struct *mm, > return res; > > prealloc_fail: > + if (anon_dup) > + unlink_anon_vmas(anon_dup); > + > anon_vma_fail: > if (merge_prev) > vma_next(vmi);