Message ID | 20230330133822.66271-1-mathieu.desnoyers@efficios.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:b0ea:0:b0:3b6:4342:cba0 with SMTP id b10csp1157960vqo; Thu, 30 Mar 2023 07:13:07 -0700 (PDT) X-Google-Smtp-Source: AKy350ZA7h78J9kMJJQUB5NyIwB6emlcdSpzZuZ7LbPj5UXOimmIzRLlJwHz8wXCbamqf7I8h2PV X-Received: by 2002:aa7:db82:0:b0:502:6e48:65ea with SMTP id u2-20020aa7db82000000b005026e4865eamr2866004edt.12.1680185587622; Thu, 30 Mar 2023 07:13:07 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1680185587; cv=none; d=google.com; s=arc-20160816; b=xrHCQcRuCQpxR7ecOG81Udwip3eipOc81UZdDJ0cJJDVMgxBib4m2piP9Lc1REmfNW k2L7iaKeruHlwhcEd9m+lwgC7j0dLpg9f4oLkV80O4olLImNTvz9r7aPgvxUqRHVdT3T v8qUJ7prQb/WaEZRerYFqtw1r9E7U397NwWePQGYelvV1FVjhVSEUGsMj6Ay9vAH6dMh 3Nv0aWrDOkJ1cStVKYpOVIsvEBfL6YigBrR66aVo0K24q3dN2Cbr9EpftYa8fwoulMrW pLfQQPMSIWKTwHPGSnwMD6PwERqnO27LxroK66g3hbPEQBIVsbxMZSq2Yx0mbJG/lmC3 lqJw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from:dkim-signature; bh=0nUFSWTH+dq2O0oPA4e8gRkiYcTYRopJHWblcq48W2o=; b=wNNl4u96eU/AISDXiUHzrlJAfPAuDZs7kZXdCiFHWrRQTGJfVK7cQUjujCUiltOuvc OwzmcwNdfBtrsb/BISUX75wQou8a/NAKdkdcIbDJ+Fpyf2FaCK2CE3pM8oXFkvX97hDW LorG0B2yWxMIvjr2I0k8sCeLJuPXoXEKa5YAWDCUpFKcK6h54KYGGDz3Fj+LLDjHaXrV j6v8JyWc1pLY+7QyBsUBN8quhA+x876IZ4d5I6YHwm0MaImujvIA/Eip/XxVIdYoEgdx 0FumF+jR4STWVSrU+vywKAem03O+sBnauJWL5NnrCXysb1p1HzxkkgLa4b+61feHtz9D /hfw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@efficios.com header.s=smtpout1 header.b=P4hVo2EZ; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=efficios.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id s16-20020aa7d790000000b005002aad5850si33811530edq.589.2023.03.30.07.12.42; Thu, 30 Mar 2023 07:13:07 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@efficios.com header.s=smtpout1 header.b=P4hVo2EZ; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=efficios.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230476AbjC3Nin (ORCPT <rfc822;rua109.linux@gmail.com> + 99 others); Thu, 30 Mar 2023 09:38:43 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:49940 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229966AbjC3Nil (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Thu, 30 Mar 2023 09:38:41 -0400 Received: from smtpout.efficios.com (smtpout.efficios.com [167.114.26.122]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 9ECCDB44C; Thu, 30 Mar 2023 06:38:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=efficios.com; s=smtpout1; t=1680183504; bh=24hs/GAOgBlVSR4B3MD3Qa1OeM+tlMUGandZTll4v9o=; h=From:To:Cc:Subject:Date:From; b=P4hVo2EZZRdByxjRo59jz0QLN9PDmvFRp1opXBJvMaYkvg2EASQ9fPugdPpcXsu2g LOhcUyR2joIXhVYMOdYsHnPIav9cWlqmrlCblMZsHRbJYibESdYmYRvnaRjADKiqm5 j0zdo2Dfqi06FIVg6EH6dYNbEuAj2JMMbpnSVlA+RdMWr8f/BudEMQvMNsMMSwnwZA CPQFJNB/IBo7aYkNiOJskGnM2Vqdqdvd3IjhFyE5TRZ0pKI0KBZhKf2zlNkXwpr/3E UEb7ynurlSL8qN/y3zJcu43QACN215cPl2d/UcsZfRnBrhjoR3E7rV7enw90eVURDy ISZ5k5GBWUw0Q== Received: from localhost.localdomain (192-222-143-198.qc.cable.ebox.net [192.222.143.198]) by smtpout.efficios.com (Postfix) with ESMTPSA id 4PnPdD01kRztMX; Thu, 30 Mar 2023 09:38:23 -0400 (EDT) From: Mathieu Desnoyers <mathieu.desnoyers@efficios.com> To: Andrew Morton <akpm@linux-foundation.org> Cc: linux-kernel@vger.kernel.org, Mathieu Desnoyers <mathieu.desnoyers@efficios.com>, Shakeel Butt <shakeelb@google.com>, Marek Szyprowski <m.szyprowski@samsung.com>, linux-mm@kvack.org, stable@vger.kernel.org Subject: [PATCH 1/1] mm: Fix memory leak on mm_init error handling Date: Thu, 30 Mar 2023 09:38:22 -0400 Message-Id: <20230330133822.66271-1-mathieu.desnoyers@efficios.com> X-Mailer: git-send-email 2.25.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-0.2 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,DKIM_VALID_EF,SPF_HELO_NONE,SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1761802282508791186?= X-GMAIL-MSGID: =?utf-8?q?1761802282508791186?= |
Series |
[1/1] mm: Fix memory leak on mm_init error handling
|
|
Commit Message
Mathieu Desnoyers
March 30, 2023, 1:38 p.m. UTC
commit f1a7941243c1 ("mm: convert mm's rss stats into percpu_counter")
introduces a memory leak by missing a call to destroy_context() when a
percpu_counter fails to allocate.
Before introducing the per-cpu counter allocations, init_new_context()
was the last call that could fail in mm_init(), and thus there was no
need to ever invoke destroy_context() in the error paths. Adding the
following percpu counter allocations adds error paths after
init_new_context(), which means its associated destroy_context() needs
to be called when percpu counters fail to allocate.
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Cc: Shakeel Butt <shakeelb@google.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Marek Szyprowski <m.szyprowski@samsung.com>
Cc: linux-mm@kvack.org
Cc: stable@vger.kernel.org # 6.2
---
kernel/fork.c | 1 +
1 file changed, 1 insertion(+)
Comments
On Thu, Mar 30, 2023 at 09:38:22AM -0400, Mathieu Desnoyers wrote: > commit f1a7941243c1 ("mm: convert mm's rss stats into percpu_counter") > introduces a memory leak by missing a call to destroy_context() when a > percpu_counter fails to allocate. > > Before introducing the per-cpu counter allocations, init_new_context() > was the last call that could fail in mm_init(), and thus there was no > need to ever invoke destroy_context() in the error paths. Adding the > following percpu counter allocations adds error paths after > init_new_context(), which means its associated destroy_context() needs > to be called when percpu counters fail to allocate. > Fixes: f1a7941243c1 ("mm: convert mm's rss stats into percpu_counter") > Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com> > Cc: Shakeel Butt <shakeelb@google.com> > Cc: Andrew Morton <akpm@linux-foundation.org> > Cc: Marek Szyprowski <m.szyprowski@samsung.com> > Cc: linux-mm@kvack.org > Cc: stable@vger.kernel.org # 6.2 Acked-by: Shakeel Butt <shakeelb@google.com>
On Thu, 30 Mar 2023 09:38:22 -0400 Mathieu Desnoyers <mathieu.desnoyers@efficios.com> wrote: > commit f1a7941243c1 ("mm: convert mm's rss stats into percpu_counter") > introduces a memory leak by missing a call to destroy_context() when a > percpu_counter fails to allocate. > > Before introducing the per-cpu counter allocations, init_new_context() > was the last call that could fail in mm_init(), and thus there was no > need to ever invoke destroy_context() in the error paths. Adding the > following percpu counter allocations adds error paths after > init_new_context(), which means its associated destroy_context() needs > to be called when percpu counters fail to allocate. > > ... > > --- a/kernel/fork.c > +++ b/kernel/fork.c > @@ -1171,6 +1171,7 @@ static struct mm_struct *mm_init(struct mm_struct *mm, struct task_struct *p, > fail_pcpu: > while (i > 0) > percpu_counter_destroy(&mm->rss_stat[--i]); > + destroy_context(mm); > fail_nocontext: > mm_free_pgd(mm); > fail_nopgd: Is there really a leak? I wasn't able to find a version of init_new_context() which performs allocation.
On Thu, Mar 30, 2023 at 12:42 PM Andrew Morton <akpm@linux-foundation.org> wrote: > > On Thu, 30 Mar 2023 09:38:22 -0400 Mathieu Desnoyers <mathieu.desnoyers@efficios.com> wrote: > > > commit f1a7941243c1 ("mm: convert mm's rss stats into percpu_counter") > > introduces a memory leak by missing a call to destroy_context() when a > > percpu_counter fails to allocate. > > > > Before introducing the per-cpu counter allocations, init_new_context() > > was the last call that could fail in mm_init(), and thus there was no > > need to ever invoke destroy_context() in the error paths. Adding the > > following percpu counter allocations adds error paths after > > init_new_context(), which means its associated destroy_context() needs > > to be called when percpu counters fail to allocate. > > > > ... > > > > --- a/kernel/fork.c > > +++ b/kernel/fork.c > > @@ -1171,6 +1171,7 @@ static struct mm_struct *mm_init(struct mm_struct *mm, struct task_struct *p, > > fail_pcpu: > > while (i > 0) > > percpu_counter_destroy(&mm->rss_stat[--i]); > > + destroy_context(mm); > > fail_nocontext: > > mm_free_pgd(mm); > > fail_nopgd: > > Is there really a leak? I wasn't able to find a version of > init_new_context() which performs allocation. > There are more than 20 archs defining this function and I couldn't check each one of them. I think we can assume there might be new allocation in the future.
On 2023-03-30 15:42, Andrew Morton wrote: > On Thu, 30 Mar 2023 09:38:22 -0400 Mathieu Desnoyers <mathieu.desnoyers@efficios.com> wrote: > >> commit f1a7941243c1 ("mm: convert mm's rss stats into percpu_counter") >> introduces a memory leak by missing a call to destroy_context() when a >> percpu_counter fails to allocate. >> >> Before introducing the per-cpu counter allocations, init_new_context() >> was the last call that could fail in mm_init(), and thus there was no >> need to ever invoke destroy_context() in the error paths. Adding the >> following percpu counter allocations adds error paths after >> init_new_context(), which means its associated destroy_context() needs >> to be called when percpu counters fail to allocate. >> >> ... >> >> --- a/kernel/fork.c >> +++ b/kernel/fork.c >> @@ -1171,6 +1171,7 @@ static struct mm_struct *mm_init(struct mm_struct *mm, struct task_struct *p, >> fail_pcpu: >> while (i > 0) >> percpu_counter_destroy(&mm->rss_stat[--i]); >> + destroy_context(mm); >> fail_nocontext: >> mm_free_pgd(mm); >> fail_nopgd: > > Is there really a leak? I wasn't able to find a version of > init_new_context() which performs allocation. AFAIU, at least on powerpc: arch/powerpc/mm/book3s64/mmu_context.c: init_new_context() calls radix__init_new_context() or hash__init_new_context() which leak IDs through ida_alloc_range. Thanks, Mathieu
diff --git a/kernel/fork.c b/kernel/fork.c index c0257cbee093..c983c4fe3090 100644 --- a/kernel/fork.c +++ b/kernel/fork.c @@ -1171,6 +1171,7 @@ static struct mm_struct *mm_init(struct mm_struct *mm, struct task_struct *p, fail_pcpu: while (i > 0) percpu_counter_destroy(&mm->rss_stat[--i]); + destroy_context(mm); fail_nocontext: mm_free_pgd(mm); fail_nopgd: