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 11CA8C46467 for ; Thu, 5 Jan 2023 00:06:42 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 9AF9A8E0003; Wed, 4 Jan 2023 19:06:41 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 9602A8E0001; Wed, 4 Jan 2023 19:06:41 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8289B8E0003; Wed, 4 Jan 2023 19:06:41 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 702DA8E0001 for ; Wed, 4 Jan 2023 19:06:41 -0500 (EST) Received: from smtpin02.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 4597C1A02D8 for ; Thu, 5 Jan 2023 00:06:41 +0000 (UTC) X-FDA: 80318804202.02.F25E0EA Received: from mail-yw1-f182.google.com (mail-yw1-f182.google.com [209.85.128.182]) by imf10.hostedemail.com (Postfix) with ESMTP id B3B10C000A for ; Thu, 5 Jan 2023 00:06:39 +0000 (UTC) Authentication-Results: imf10.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=TKQFqzcm; spf=pass (imf10.hostedemail.com: domain of surenb@google.com designates 209.85.128.182 as permitted sender) smtp.mailfrom=surenb@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1672877199; a=rsa-sha256; cv=none; b=vop27oHPkUPWsAz/gKFa1ijXuwQJRsg1OyiKKA+K7euJna51HFMRGt6oeVCF5vuyKqfAqa zbEhMYPLHUnEZVjSivaAaMNbL6XIMRrNlRrIrGNYYCzHUloy8Qxrcyrc3hrqqUHnAZzGe+ Xh/4H23G+3zMTntLj+OZgvd5G5qUFqo= ARC-Authentication-Results: i=1; imf10.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=TKQFqzcm; spf=pass (imf10.hostedemail.com: domain of surenb@google.com designates 209.85.128.182 as permitted sender) smtp.mailfrom=surenb@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1672877199; 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=ugktJCe/HSjFId4CkvvJ5v4nvujpVuUxkVJVsSWOUE4=; b=nU1aoGx9GGH71FLx03XZqxPFzN7Hm9wWvyW2CylbhPl4KXfispnF9SQABv1dn/cgOW75eE jJA6GIUCN/Wm7I3/TPWaEZSvNnrFd0WJDoVhvKs9BS6op8tfXu10/k1O2kiBFcoYukMRsI 54e7yIgQTdRiJH7EBSLVDlti4TpzLks= Received: by mail-yw1-f182.google.com with SMTP id 00721157ae682-46198b81e5eso498285337b3.4 for ; Wed, 04 Jan 2023 16:06:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=ugktJCe/HSjFId4CkvvJ5v4nvujpVuUxkVJVsSWOUE4=; b=TKQFqzcmuwTVyi3fjqE0c6JtCZpLG69JEMvwQ6VAsL1vYaWS8jl8Ysb6ZsxhwK4DMG DLtJmfrmqSb+cdaJSbcFxZB58lhBSf6ZDJcM4rhBHpZPZRNy6jPxx9LM28XFK590uVgS VxOgvPfEVks3f11jgxvLz0zfljElFhSVgMbiawbY0+oetVr77HuynqiIDa2OJ8m49HJy yR1PrjDL9tlL84h6s14i7dTGbiI23YdKK3m/ezLpMwmRerur7GGw13WD1pMz/TcNCCjx Nmmdw1vWw+he73L7aPwbQqDb9gP+pba9Ydir8bWW/K7aodV3UnOz/RokArKRRp3JexgF E8TQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=ugktJCe/HSjFId4CkvvJ5v4nvujpVuUxkVJVsSWOUE4=; b=ztcBNnslQF4pMZj0/r5IaO2FAhoPrgaq0pmlrCClvDhsOQ8Er4PvPOhj4+Em8rGElx mcZ0dxKiDos5/qpnPjypPDcG3bloRxqL4acz9VNzeKSWEo1LmN8vZvUGiEBvKcxSY9pg JN+8Ey4qBmuvSYXO2ceUqOrw42ERtCCzRFkpGIMdyX7oEti4od1HRH6dKbg5yJRlWpNa OpBBZpP+C6t4pvm+taMYGejRYlFwjJ6KTxhJhZ9JlbdW7piPFY8C23qOuNOYXndeyQ7U UA2uaTGAqnc0u2n41/VNFUvZIyHdRb84kn8lX4wYgMymDtqMoM7W+ZWWQ3a5Xx894Tu7 8TOQ== X-Gm-Message-State: AFqh2kqZwrvvrcqVY6/n6UceNXL6Fa1CTAMjmS05FlBzYCBW1JR/9wg6 r5Be1w1Nc6LrIgjIq8WWPdy4+ktJMfnTUdQ8Q9GlVw== X-Google-Smtp-Source: AMrXdXv+nX87Qe/hYWQukdNnIqreUBCRunYKkfj5vDDQx2RKVFT5PrGFmLA/MfY9YJN1/ZjG81CVeT/yDqJFSHSUz+g= X-Received: by 2002:a81:9210:0:b0:3dc:fd91:ef89 with SMTP id j16-20020a819210000000b003dcfd91ef89mr5295477ywg.347.1672877198588; Wed, 04 Jan 2023 16:06:38 -0800 (PST) MIME-Version: 1.0 References: <20221228194249.170354-1-surenb@google.com> <6ddb468a-3771-92a1-deb1-b07a954293a3@redhat.com> In-Reply-To: From: Suren Baghdasaryan Date: Wed, 4 Jan 2023 16:06:27 -0800 Message-ID: Subject: Re: [PATCH 1/1] mm: fix vma->anon_name memory leak for anonymous shmem VMAs To: David Hildenbrand Cc: akpm@linux-foundation.org, hughd@google.com, hannes@cmpxchg.org, vincent.whitchurch@axis.com, seanjc@google.com, rppt@kernel.org, shy828301@gmail.com, pasha.tatashin@soleen.com, paul.gortmaker@windriver.com, peterx@redhat.com, vbabka@suse.cz, Liam.Howlett@oracle.com, ccross@google.com, willy@infradead.org, arnd@arndb.de, cgel.zte@gmail.com, yuzhao@google.com, bagasdotme@gmail.com, suleiman@google.com, steven@liquorix.net, heftig@archlinux.org, cuigaosheng1@huawei.com, kirill@shutemov.name, linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, syzbot+91edf9178386a07d06a7@syzkaller.appspotmail.com Content-Type: text/plain; charset="UTF-8" X-Rspam-User: X-Rspamd-Queue-Id: B3B10C000A X-Rspamd-Server: rspam01 X-Stat-Signature: k1yx3g7jcaueas6af78wzi3qqsujftf9 X-HE-Tag: 1672877199-904215 X-HE-Meta: U2FsdGVkX18oLGUxrvsnVd4XDwOP9d/9BGLz1/VB6tLtFkrnFnl1z82KPSb+Up9VxYtqfWE0FIvRVBLVuqjS7xjQ8ksDG2mRyzI6LuGfQygzIcb0LyvpWdok/4613YCrz/6VXLdzTZELbg4qn+nZYdTXdu5CllYXc9/lVOvWdL17sbkjAgJ1hKn/45IIUuOBXvVh5fO951G81h4SJKekWDog1zgQv6eVRa4XfUxA7L9m/yYEyOC/5+q4fsHcdFT4hKYNKUxUCAhKwuMFHISSOzrMyfRH2pQNjbLlTkkb9aMP7jC8bWSO+/IAODS1tdWClEj7WRa/X4H2VtigN9ku8V7CJZQgUEXHwykfM47tU1wDSLWBFEYAMA2NW6cM+bSfn+iG4+JUxDL1cGBVp5RxsEgU8W2LJAWIhLwjoUMSoP8MX4i1GbtdFqFG79aSRf4UBeFuLQIKSqY11LXWQw6/3/z98Q2xE86dXd0GGije4ZvJslWmHFTyBro9ksGLK2J+3LI4Mau8s1lZFOFC+wY/tpVW6dv4ddRqSrXkB6KUS9SoJz/jt14xJEo+qLwfTAHcYSdnsOtTE/MrIWCazJuaY8gtMqlFNxcTTRzybE7x63f1HBXohLkzKSaPXvRRmDEat8p3rmNfLALyM7yCewC0oH+3NADqmrtrVqStn9Au6yiRUNEZXoa6EZK0noDbm7KBc5hX3bYP2kImthCe/peQlEXnxc9GblgyDThyIeLGh7ntvuI3g6jQr7rdFrJlmr1pwbHpm/Mtz8wmj7fs3Cwe0AVV+54tvMAY6ePq0vYbf6jhWtutP9vvm8OxIS73OCSHE96w1efIfFUmOXXWLu1B+8+9tg6s9jNSJrCM0BxSC2V2GW1XIWbq3rtt1Arm1RPXLl6W9Aout8cyxsQc8JOa0Q9K1l6O1VwmM4k5mXAmrRLHx9JPhwxfk6p4M5qKZfzLgdzHDIcEo6HFQlu1+gj T9NJzVvl bAZIfa6g4Drfe/o2OcV+qEBKgm00fNUxJaWHvX8Sc+xLM4wAf2ZU6w9RNDHJcPOX1u6ofckm34FDpq7+4bdXFOQoNNL3HXGwQPrTTHoA3YKQrpwvoxRQXJttdQwGyO8vX/VfzFJkEmHCMkH4wRat3wjpt7XyVuhsXhIeN 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 Wed, Jan 4, 2023 at 10:24 AM Suren Baghdasaryan wrote: > > On Wed, Jan 4, 2023 at 1:04 AM David Hildenbrand wrote: > > > > On 03.01.23 20:53, Suren Baghdasaryan wrote: > > > On Mon, Jan 2, 2023 at 4:00 AM David Hildenbrand wrote: > > >> > > >> On 28.12.22 20:42, Suren Baghdasaryan wrote: > > >>> free_anon_vma_name() is missing a check for anonymous shmem VMA which > > >>> leads to a memory leak due to refcount not being dropped. Fix this by > > >>> adding the missing check. > > >>> > > >>> Fixes: d09e8ca6cb93 ("mm: anonymous shared memory naming") > > >>> Reported-by: syzbot+91edf9178386a07d06a7@syzkaller.appspotmail.com > > >>> Signed-off-by: Suren Baghdasaryan > > >>> --- > > >>> include/linux/mm_inline.h | 2 +- > > >>> 1 file changed, 1 insertion(+), 1 deletion(-) > > >>> > > >>> diff --git a/include/linux/mm_inline.h b/include/linux/mm_inline.h > > >>> index e8ed225d8f7c..d650ca2c5d29 100644 > > >>> --- a/include/linux/mm_inline.h > > >>> +++ b/include/linux/mm_inline.h > > >>> @@ -413,7 +413,7 @@ static inline void free_anon_vma_name(struct vm_area_struct *vma) > > >>> * Not using anon_vma_name because it generates a warning if mmap_lock > > >>> * is not held, which might be the case here. > > >>> */ > > >>> - if (!vma->vm_file) > > >>> + if (!vma->vm_file || vma_is_anon_shmem(vma)) > > >>> anon_vma_name_put(vma->anon_name); > > >> > > >> Wouldn't it be me more consistent to check for "vma->anon_name"? > > >> > > >> That's what dup_anon_vma_name() checks. And it's safe now because > > >> anon_name is no longer overloaded in vm_area_struct. > > > > > > Thanks for the suggestion, David. Yes, with the recent change that > > > does not overload anon_name, checking for "vma->anon_name" would be > > > simpler. I think we can also drop anon_vma_name() function now > > > (https://elixir.bootlin.com/linux/v6.2-rc2/source/mm/madvise.c#L94) > > > since vma->anon_name does not depend on vma->vm_file anymore, remove > > > the last part of this comment: > > > https://elixir.bootlin.com/linux/v6.2-rc2/source/include/linux/mm_types.h#L584 > > > and use vma->anon_name directly going forward. If all that sounds > > > good, I'll post a separate patch implementing all these changes. > > > So, for this patch I would suggest keeping it as is because > > > functionally it is correct and will change this check along with other > > > corrections I mentioned above in a separate patch. Does that sound > > > good? > > > > Works for me. > > > > Acked-by: David Hildenbrand > > Thank you! Will post the followup cleanup patch shorly. Andrew, I posted v2 of this patch at https://lore.kernel.org/all/20230105000241.1450843-1-surenb@google.com/. Please replace the original one in your tree. I had to follow David's original suggestion instead of my planned cleanup because removing anon_vma_name() would require us to add #ifdef CONFIG_ANON_VMA_NAME everywhere we use vma->anon_name, which is quite ugly. Thanks, Suren. > > > > > for this one, as it fixes the issue. > > > > -- > > Thanks, > > > > David / dhildenb > >