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 3BA8FC4332F for ; Wed, 2 Nov 2022 07:46:37 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 647476B0071; Wed, 2 Nov 2022 03:46:36 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 5F8AA6B0072; Wed, 2 Nov 2022 03:46:36 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 4BE316B0073; Wed, 2 Nov 2022 03:46:36 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 3BCDE6B0071 for ; Wed, 2 Nov 2022 03:46:36 -0400 (EDT) Received: from smtpin28.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id E607F41134 for ; Wed, 2 Nov 2022 07:46:35 +0000 (UTC) X-FDA: 80087719950.28.9A7B048 Received: from mail-pl1-f176.google.com (mail-pl1-f176.google.com [209.85.214.176]) by imf07.hostedemail.com (Postfix) with ESMTP id 98A2B40002 for ; Wed, 2 Nov 2022 07:46:34 +0000 (UTC) Received: by mail-pl1-f176.google.com with SMTP id c24so15794339pls.9 for ; Wed, 02 Nov 2022 00:46:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; 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=NUw9xWmpIf0XS62mp9HMnjP0huIdNjfhlXFV3m0hYXU=; b=ALwiQ3aIbPe1VylTTzdBSb36+7VaoGpR40jzyMrSs+dWBsj61OkBBotNGw2KFClzWu eZVG4iT1Q1ikdYQsG49wDAR4YH0KvxRWkGTmqQ4yGn9PLXpewid9khtyHRLkXn1Ybm7n ueoe569BEuZBjz6JqPqYqEfyBLAvNQ7ZAJZY0As9oUivEw2rMva0ZaPLBwZMAr+eKU59 3Dq+DNeefM6yXYdvpIsP3lwVZ3p2ZOxtS7M0sqigJ+LrwS7uxH/YNUVaEOzcq6MeTXSa tvHMc7zW4WBaq/5dDyKeba+6Wb/EzIvNbAk0GfNLYfUnFUD5B4VPyIbRRUvc8OGEww7J 5I8Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; 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=NUw9xWmpIf0XS62mp9HMnjP0huIdNjfhlXFV3m0hYXU=; b=YUnNSE36jVggMlKWBu5TBFf3ZitRwB+aIZBByrfujAF4cp7A83NULGA1EHIS0WRgRm OcJpjfrlDdzrsAZJrwPasFeX6VCQxwlHCbBb66KjgGb7e508y9RTWWch/qAsVb0blALh S9qCl8tAo1V9Y1em+3AXR/Yx7YUNsNhMClQkgBAHC0crSJN4n4bAv3wdp0wsZeNbUWkA JrYdL9zjc4bXebNTVlbP8FxKiO0sEi7hHTqPH8Ev21uc0DKXgVcVpuSDxJl2IrfAG3ff s1Ox5daMlmjcWRND/FGWcDFWJVmJNkZ1N3wNUW82U/8JIXoJDI43e2MDu7MLHDT+vz2a 2k3A== X-Gm-Message-State: ACrzQf1jll7bMw0Z6x6u2d42rlMy8KUqlcRSv9UOvEEZZGt+l3/ds867 WX0VRxOsYFMyib5Vb/FKWnU= X-Google-Smtp-Source: AMsMyM5g0umuJwKDdnxNghIjoT8k4b5z28vu7fFz2BeFZE9cAw7CylIrWGBIXzYsDsHIP5BIUQkS5w== X-Received: by 2002:a17:90a:f0d1:b0:213:473e:6ff0 with SMTP id fa17-20020a17090af0d100b00213473e6ff0mr23905780pjb.87.1667375193476; Wed, 02 Nov 2022 00:46:33 -0700 (PDT) Received: from hyeyoo ([114.29.91.56]) by smtp.gmail.com with ESMTPSA id q17-20020a17090311d100b00186985198a4sm7631816plh.169.2022.11.02.00.46.30 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 02 Nov 2022 00:46:32 -0700 (PDT) Date: Wed, 2 Nov 2022 16:46:27 +0900 From: Hyeonggon Yoo <42.hyeyoo@gmail.com> To: Liu Shixin Cc: Christoph Lameter , Pekka Enberg , David Rientjes , Joonsoo Kim , Andrew Morton , Vlastimil Babka , Roman Gushchin , linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v2 0/3] Refactor __kmem_cache_create() and fix memory leak Message-ID: References: <20221031134747.3049593-1-liushixin2@huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20221031134747.3049593-1-liushixin2@huawei.com> ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1667375194; 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=NUw9xWmpIf0XS62mp9HMnjP0huIdNjfhlXFV3m0hYXU=; b=ZEuviOfdYHw2jBycNnKd8qHyiN/TdqkE3kLNhoCBRZRuFW6cPEGBNoORizU9ydc0wiiknp 6WXGce8yBgFcPiao3ZiY2umKimDxocV4aTTP6D2jqKDk5rczTIPtwiGgmC68Gqp+CMLzIJ yOz4l1W2G74s1jy3AhOr02RPm4Z0Phw= ARC-Authentication-Results: i=1; imf07.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=ALwiQ3aI; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf07.hostedemail.com: domain of 42.hyeyoo@gmail.com designates 209.85.214.176 as permitted sender) smtp.mailfrom=42.hyeyoo@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1667375194; a=rsa-sha256; cv=none; b=tL5f13iLCFJ1sgA0SybLlAEixbm5LCmEnhOoAcTNqQndszCs/wFSn4PSzBQEYw4o2V+Ec4 pE3LtBOl3pbT8umg4rERnD8h9bgFH8X/o8qoxDWGbYv27hIIOJIlcBolAn6U0+qZ24UjL5 sMm6U41BXT9A3zgjgK62P+N6kPa1Wik= Authentication-Results: imf07.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=ALwiQ3aI; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf07.hostedemail.com: domain of 42.hyeyoo@gmail.com designates 209.85.214.176 as permitted sender) smtp.mailfrom=42.hyeyoo@gmail.com X-Rspam-User: X-Rspamd-Server: rspam08 X-Rspamd-Queue-Id: 98A2B40002 X-Stat-Signature: bd9q8gitdbcf9yhnzbouc9pp5ajwek6o X-HE-Tag: 1667375194-759865 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 31, 2022 at 09:47:44PM +0800, Liu Shixin wrote: > I found a memory leak of kobj->name in sysfs_slab_add() which is introduced > by 80da026a8e5d ("mm/slub: fix slab double-free in case of duplicate sysfs filename"). > Following the rules stated in the comment for kobject_init_and_add(): Thank you for reporting this! Indeed it seems tried to fix double free but introduced a leak. > If this function returns an error, kobject_put() must be called to > properly clean up the memory associated with the object. > > We should use kobject_put() to free kobject. But what to do if a cache is created early and later sysfs_slab_add() failed? (Which is unlikely on normal condition) With this series it introduces use-after-free if sysfs_slab_add() in slab_sysfs_init() failed. Should we just call BUG() or something like that? > But we can't simply add kobject_put() since it will free kmem_cache too. > If we use kobject_put(), we need to skip other release functions. > > In this series, We refactor the code to separate sysfs_slab_add() and > debugfs_slab_add() from __kmem_cache_create(), and then use kobject_put() > to free kobject in sysfs_slab_add(). This can fix the memory leak of > kobject->name. > > v1->v2: Fix build error reported by kernel test robot . > > Liu Shixin (3): > mm/slab_common: Move cache_name to create_cache() > mm/slub: Refactor __kmem_cache_create() > mm/slub: Fix memory leak of kobj->name in sysfs_slab_add() > > include/linux/slub_def.h | 11 +++++++++ > mm/slab_common.c | 44 ++++++++++++++++++---------------- > mm/slub.c | 52 ++++++++++------------------------------ > 3 files changed, 48 insertions(+), 59 deletions(-) > > -- > 2.25.1 > -- Thanks, Hyeonggon