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 40A75E7849A for ; Mon, 2 Oct 2023 07:43:48 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 80B948D000B; Mon, 2 Oct 2023 03:43:47 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 7B90D8D0001; Mon, 2 Oct 2023 03:43:47 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6A8A38D000B; Mon, 2 Oct 2023 03:43:47 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 5756F8D0001 for ; Mon, 2 Oct 2023 03:43:47 -0400 (EDT) Received: from smtpin13.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 2028A4017A for ; Mon, 2 Oct 2023 07:43:47 +0000 (UTC) X-FDA: 81299732094.13.0BF755A Received: from mail-lf1-f46.google.com (mail-lf1-f46.google.com [209.85.167.46]) by imf01.hostedemail.com (Postfix) with ESMTP id 41AF840003 for ; Mon, 2 Oct 2023 07:43:44 +0000 (UTC) Authentication-Results: imf01.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=OY9wlGd9; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf01.hostedemail.com: domain of lstoakes@gmail.com designates 209.85.167.46 as permitted sender) smtp.mailfrom=lstoakes@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1696232625; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=o+nReRagUozu8z0tWV2+jg0w12ucMifR6ov/hT+a2As=; b=hhGbd8bagU7rFHg9Q4/Lty3CjMr5FnAhX+ur0muRKzBHmuskj1j6Z0MV+cECzD2xuFYe1b nH2WUjCcGM32H3ZXsU9Q2XHJGx6dBwUcb3LI6kek5t7DEhlVLq7a7WHMaqHlJV1qJrYpc3 bfvbd6lwqTknzsT7B6sKtp9JYkn2uYg= ARC-Authentication-Results: i=1; imf01.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=OY9wlGd9; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf01.hostedemail.com: domain of lstoakes@gmail.com designates 209.85.167.46 as permitted sender) smtp.mailfrom=lstoakes@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1696232625; a=rsa-sha256; cv=none; b=UcIb9yyAooYTW7MLmQLZbrFuPlMJCCCvrZ8odhX1+l17xJ91qitEODsW8JF58uBAgt8wQ7 snRLZMjuNLp3K4Fk4rXZYYhV80KsLa1o9o6jjZ/mhJufkWtqYLJfZQ8V10QLJb8ONZpNQr 9sAI7eFRqhOtUNhPsZZr9+muZ9oj8PY= Received: by mail-lf1-f46.google.com with SMTP id 2adb3069b0e04-5033918c09eso24798546e87.2 for ; Mon, 02 Oct 2023 00:43:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1696232623; x=1696837423; darn=kvack.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=o+nReRagUozu8z0tWV2+jg0w12ucMifR6ov/hT+a2As=; b=OY9wlGd9Enr+bBvexQvQdQ/68CgVYKrxflIL8V9r5lgAdY6gT7ZNQV/HCPw81rgUog d5nWuqRI1SBr9ffMQNmpaYSslliHHhZGU7w2eo6p+wEQMQS/4U46RmoWR8r7fZIm1BsW g43AyJznwpLSfnKU6RFTm+HjzQIxNNkHpEYeiA2T49NUSnVHNg7mCVD5qyIzUjTLdulD giGWLyEFaXmg4U6GhoZPGWVr3GhSKVkoVFXcAS4LI58L2BRiiB4GN6AIhO20a3NwD3vo JhU1ck6Z5DXEjNuwTDPx8lUDLIqSOzcmwgYpgOnZ4gPkHmYhCxpbDPdXuAWQ95F+gnKN npiw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1696232623; x=1696837423; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=o+nReRagUozu8z0tWV2+jg0w12ucMifR6ov/hT+a2As=; b=L29tjESizAeFxQZfMrUfdB7CvYq3bl60KWnSAxLln1RfYbM9NFePaWn/N8Dd8xtHU2 mu8jIQgdlP1x3xkTm4g6/mZ8nKTWrl0ErodAxySbcYxTnUf/6dDJ+6DB7ZCx/4ii0+sZ CxeVamf1+fo1unMtkv4KTc0rhF2yEo72XE+YsV9eXproSTgUnOJ6jgekcMM/z1nTYbJm K98fcqjH6HJBPx7g8pfzU7FVS/g9G9xM4dTcia97SdcwSYdXW/sGYYX0Uu2XVORx0s1K 2wZ+YWRGiM6s1VzGv9WDhbNOB6Mbors91ggCLNwZEVCpoKIsOyLt9D/Xeke1jmtpE2dB ddKw== X-Gm-Message-State: AOJu0YzZOEQojZBJU8bclKzdjhBIEr0tXezn0Qmb8/SIUoDryi3fuG0C EH6nQ0HhVLMCMLwIblE2aLM= X-Google-Smtp-Source: AGHT+IEEisoHnB4dHSYvzwRawwJ8vQwMufIusH62krxfUfH8omy30RCu3+e/jnlvbnT0qcWMK+gjsQ== X-Received: by 2002:a19:7b0b:0:b0:503:1ca6:c590 with SMTP id w11-20020a197b0b000000b005031ca6c590mr6238199lfc.22.1696232623342; Mon, 02 Oct 2023 00:43:43 -0700 (PDT) Received: from localhost ([2a00:23c5:dc8c:8701:1663:9a35:5a7b:1d76]) by smtp.gmail.com with ESMTPSA id a11-20020a05600c2d4b00b004065daba6casm6541786wmg.46.2023.10.02.00.43.42 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 02 Oct 2023 00:43:42 -0700 (PDT) Date: Mon, 2 Oct 2023 08:43:41 +0100 From: Lorenzo Stoakes To: Vlastimil Babka Cc: "Liam R. Howlett" , Andrew Morton , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Jann Horn , Suren Baghdasaryan , Matthew Wilcox , stable@vger.kernel.org Subject: Re: [PATCH v3 2/3] mmap: Fix error paths with dup_anon_vma() Message-ID: <6f85e46d-78e3-426d-9a24-3aadfd91bdc6@lucifer.local> References: <20230929183041.2835469-1-Liam.Howlett@oracle.com> <20230929183041.2835469-3-Liam.Howlett@oracle.com> <843f059f-dd54-4481-b46a-e87e56274db3@lucifer.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 41AF840003 X-Rspam-User: X-Rspamd-Server: rspam04 X-Stat-Signature: x5kg4fii6u4gbo5injqi6u6zjgbcc7si X-HE-Tag: 1696232624-485615 X-HE-Meta: U2FsdGVkX18J/IAUvouxUs+c4ktkcxpbnSAvcdMycMdnnslVNlsNF0ZbBtPhpAh0QSTfb+eRhlOq9xv7bV8EXPcnpKDu6Bk99b3m+OLea7ENIvioMrbgp/eHXcanxXorBSdvI5juKUMPXmQiODq7jaAtIpSlXrQBztwFIytHTFrK7XmhxycSN1YP/Li0NnB5SrknpchBymmgdxTH18WEUJONiuL4V1aEygafbnPvILK9cOUbrILersBafHqappzazSudAt/6K+9A9I8PVV5noGIZP2I1HZXJ1f3qsYpTNicyReBoyI2DChALARUb0wd/MBkXEz00ezdyv42KNNxR88GRV2CuTJjsZ8OeIlck2B9CfdUFRfob9/MUYFKneKSWWvrnNIZony1svzoTZf5LtBGTqjsXJghMJ9WkkQZXd/RFNyBDKrd+w/MO9s+9RXconb+C0+TUZ3M3GnW0YGkxtmGW87DtjdJChvlpi8JHnTX2LAIAJcdZSsEPxHUueGGsn8n2AiurubwWsliJO0L4MmTDkZvwb/VTLASH+EeUqYtFEIArMPuj5gHwcTAbQqZYwSy2VhUM0wNzWcruzVucTtd8SQ8vx+OL9M0jV8pbCwFPFnYfStoQuFjauPPNnrj5/k6wicl2OXuneIA2sPwwT5EgTyaNLn4nKHWvHX0jKn9NjQB0sjGxpUY2i5CzT186ydDMuFjzKUTPtfe7B1P8b4F4hxW/nE2zUgpmpditxRckMSBLxvVwkIm/83SR+QeViTQVINb1LG70qCQ8pWG5QHwC1ByZW5CpCYOSTsMeyKOmnkQeCjEXQ4npdz3jLUa/atJy+Gwi974UvY5A2J0Sz9yj/xva+s/6PuIMGEaXGgzkLeZiqL30j+bQAvp2hjjZ1xUaIPzURus3e61AeFBt+q82Xxp8lE6r4VVaVYdlpKZqFG/jye9MyYIoA7iQcc9O41fyejNz6bDZHGmcFEs HM6GL1aD loKNsako4MjD/uYsiD1wSZFk5AVMRQgc9PE9++CSmBYmOxfFBomHG67lip37Q4P7tYR9Y99nAnKHWeC+TROXp12ICpb0Gk4py8q5OJkCtLxYc2cDVWQcs9xczwoLXZH3nNBIeaTj9PZO3GfW717/57NjG3foTG+1DBJVAHqbnV5Yuu9yR4P2IHJyTgTX1nClafRzNlYPa2/7Iq6at1IDYGFIyL02PhfG4G89qe2pu2Svtp/L3mjQe+dR7La86G9NivJf9t1O5gLa4m+JiaCVsKzNFIHWY0EELAae5HnOFVoHWZk2kwcI1DqSkjDQzPGfw+XpHbcoryAu7FoLR00MBJ8OGsRtqiA8A7ql1XwE/TC8VuhgQYP99esncgOZFUl3/XidKN/CUM4IL6ueR/OUreeY8gpXX1NeZut5ZeytangO1mX30tPw6naFc7x+WDzu43ub7kONnSwC0EZR+EAfymD67CDrtq8NaFsWJaeQNy9LXzpXc/oUd90IAhanC2ZCDyc47CF1i205F2OW4g+akTgj7/OHyYkHSZsjRhHVT/yS4yHg= 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 Mon, Oct 02, 2023 at 09:26:03AM +0200, Vlastimil Babka wrote: > On 9/30/23 00:28, Lorenzo Stoakes wrote: > > On Fri, Sep 29, 2023 at 02:30:40PM -0400, 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 | 30 ++++++++++++++++++++++-------- > >> 1 file changed, 22 insertions(+), 8 deletions(-) > >> > >> diff --git a/mm/mmap.c b/mm/mmap.c > >> index acb7dea49e23..f9f0a5fe4db4 100644 > >> --- a/mm/mmap.c > >> +++ b/mm/mmap.c > >> @@ -583,11 +583,12 @@ static inline void vma_complete(struct vma_prepare *vp, > >> * dup_anon_vma() - Helper function to duplicate anon_vma > >> * @dst: The destination VMA > >> * @src: The source VMA > >> + * @dup: Pointer to the destination VMA when successful. > >> * > >> * Returns: 0 on success. > > > > Being a bit nitpicky/refactory here, but anon_vma_clone() appears to have > > two possible return values - 0 for success, and -ENOMEM. > > > > As a result, it's not really gaining us much passing through this value. > > > > It'd be nice if dup_anon_vma() and anon_vma_clone() were therefore updated > > to instead return NULL on ENOMEM and the dst otherwise. > > But we also need to represent that dup_anon_vma() had nothing to do, because > "(src->anon_vma && !dst->anon_vma)" was false, and in that case we should > not be returning dst from there? > > So maybe we could return NULL for that case and ERR_PTR(ret) for the -ENOMEM > from anon_vma_clone() ? Yeah, you're right, actually I think that would probably be the best approach as you'd both eliminate the awkward out parameter but retain the fact that there's 3 possible return states (dup'd, no need to dup, error). > > > Then we could de-clunk this whole code path, and the quite natural fact of > > 'thing didn't return a pointer therefore had no memory to allocate it' fals > > out. > > > > But this isn't exactly an earth-shattering concern :) > > >