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 CE57AC25B06 for ; Sun, 14 Aug 2022 08:05:51 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 21EEB8D0001; Sun, 14 Aug 2022 04:05:51 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 1A8996B0074; Sun, 14 Aug 2022 04:05:51 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 04B0E8D0001; Sun, 14 Aug 2022 04:05:50 -0400 (EDT) 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 E66856B0073 for ; Sun, 14 Aug 2022 04:05:50 -0400 (EDT) Received: from smtpin31.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id B66BD1C63B0 for ; Sun, 14 Aug 2022 08:05:50 +0000 (UTC) X-FDA: 79797464460.31.E5F7F14 Received: from mail-pf1-f182.google.com (mail-pf1-f182.google.com [209.85.210.182]) by imf08.hostedemail.com (Postfix) with ESMTP id 4CDB216006A for ; Sun, 14 Aug 2022 08:05:50 +0000 (UTC) Received: by mail-pf1-f182.google.com with SMTP id h28so4422811pfq.11 for ; Sun, 14 Aug 2022 01:05:50 -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; bh=7G1ch4jQhofsf5blw9v08dA+V4yyEX/5SvBJlQvxtxI=; b=FCxkVSpdGnP2vhf/FTZow29Svf69NBFLCTu+K94SX4my/XxYZiJKr+55gFJ0gSjNV5 Tpfe6ghc/f4NXPgfYWPOO6hcx1VlItiPqsBn1cRHHruifH0yYuw9B4dUKlyay1TLfwV3 NM2Uc8ZHZA60+rp77A0XFrMM+ktTYmY73P7CiymTo2svfvgyLyF1/YHmQCTHtlFi/Dp8 i/gt9fez4ucODmSCg8ZTKqrsLL0wsrNqgCMIAkZhBayupSmRfkTte03Uw6WLqLQ0YSsC Cq/iCTf4jkamq++AfWF9776NdO9YwzbdDXavlBf8GEfT8+WMlcc96CLKiVuydF81at4l AUmQ== 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; bh=7G1ch4jQhofsf5blw9v08dA+V4yyEX/5SvBJlQvxtxI=; b=fN8k3PqjVEAbkmtIvsTacg8s3WRlCRCNCfWTv4YjOKVSQeBgvdM3ISino2Y7DDiA+5 /UJaANhJPSEJtzsiOt+U29k33fI+Y6/N4laaVR4BEjl3/39iTdLol3Q42006LJg6N+EG CABDmGBiC2tY9mpRzSwaUeoo5bwHZV7DXvh9u2YLIMMgfM7fJsEgmUTfAEJenzeF/wW3 rgbZa/tgIQ6G2imiQj6mTAsR1Eyk4iNHLvn1s8srceIxHOQwCJvLhSdOC7GUjP9+jafW ++chfoWCgdtl//86IvCj8A8DFE71/yWJ7Vff6MgVCBlO9Cqx6bDFFdW7ocg5fbYop2rZ t3Ig== X-Gm-Message-State: ACgBeo0MEO70aOvDReZUZhkqU9Pq2S1kXaYi6jGzcucjvftBeS2rlEXc kLyskV90sx2eOCc8OuWn9z0= X-Google-Smtp-Source: AA6agR57w+ju1BUaVHtUyBnWh4c1zgnWTnNyxSldfMe5xn2wB2lCKGMHsYDcZfrEFGUrbAbaIhIosA== X-Received: by 2002:a65:46c4:0:b0:41d:e36b:1e59 with SMTP id n4-20020a6546c4000000b0041de36b1e59mr9291859pgr.494.1660464349196; Sun, 14 Aug 2022 01:05:49 -0700 (PDT) Received: from hyeyoo ([114.29.91.56]) by smtp.gmail.com with ESMTPSA id x185-20020a6263c2000000b0052dc3796cbfsm4689485pfb.75.2022.08.14.01.05.45 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 14 Aug 2022 01:05:47 -0700 (PDT) Date: Sun, 14 Aug 2022 17:05:42 +0900 From: Hyeonggon Yoo <42.hyeyoo@gmail.com> To: Xin Hao Cc: cl@linux.com, penberg@kernel.org, rientjes@google.com, iamjoonsoo.kim@lge.com, akpm@linux-foundation.org, vbabka@suse.cz, roman.gushchin@linux.dev, linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH V2 1/1] mm/slub: release kobject if kobject_init_and_add failed in sysfs_slab_add Message-ID: References: <20220811071844.74020-1-xhao@linux.alibaba.com> <20220811071844.74020-2-xhao@linux.alibaba.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220811071844.74020-2-xhao@linux.alibaba.com> ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1660464350; a=rsa-sha256; cv=none; b=ohL0HEEeWqGbX4QCF85NRHjrepTjJDc8bWdVmeupV8lzFgf2pufZmc76MossSHOD4gO/pe gQqFNpg+THzFCouWSIiv04DctMNaeK++3/8LCglNuewsnoJ0/gueN9Sfzk2KmxbvJ7mhBg 9PNEeBp0Gq4XiC3Gp3AJXkh7iILMl0I= ARC-Authentication-Results: i=1; imf08.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=FCxkVSpd; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf08.hostedemail.com: domain of 42.hyeyoo@gmail.com designates 209.85.210.182 as permitted sender) smtp.mailfrom=42.hyeyoo@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1660464350; 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=7G1ch4jQhofsf5blw9v08dA+V4yyEX/5SvBJlQvxtxI=; b=1eD3TnblnjuyjRBMNDsM+lWNxQZ0BPQJNn1EAr5qQB+v6f+iLa6MsuvUKX1H8q7F+T9zLa PMSMlfdq/Tx5a8o8l1XBbiyEoL0uRsVzkUgwmTNaBf2/7U/8HFAlO3w/Hml/ixV/onFF7r SAMt6fqtzzGl47Uqg9E0xtnmnqp8cOk= X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: 4CDB216006A Authentication-Results: imf08.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=FCxkVSpd; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf08.hostedemail.com: domain of 42.hyeyoo@gmail.com designates 209.85.210.182 as permitted sender) smtp.mailfrom=42.hyeyoo@gmail.com X-Stat-Signature: 5f19dszwuyacufneo3ge4u3ieqrj9ypy X-Rspam-User: X-HE-Tag: 1660464350-672663 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 Thu, Aug 11, 2022 at 03:18:44PM +0800, Xin Hao wrote: > In kobject_init_and_add() function, the refcount is setted by calling > kobject_init() function, regardless of whether the return value is zero > or not, therefore, we must call kobject_del(&s->kobj) to prevent memory > of s->kobj is leaked. TL;DR: IIUC current code works just fine After thinking more, I don't think the memory leak you said exist. The space for s->kobj is freed in create_cache() when __kmem_cache_create() failed. The situation here is: create_cache() { s = kmem_cache_alloc(kmem_cache, GFP_KERNEL) err = __kmem_cache_create() if (err) goto out_free_cache; out_free_cache: kmem_cache_free(s) // s is freed here (including its kobject) [...] } __kmem_cache_create() { [...] err = sysfs_slab_add(); if (err) { __kmem_cache_release(s); return err; } } The primary goal of kobject_put() is to call release() function of kobj_type (when reference becomes zero), which is kmem_cache_release(). kmem_cache_release() { __kmem_cache_release(s) kfree_const(s->name) kmem_cache_free(s) } But when slab_sysfs_add() failed, __kmem_cache_release() and create_cache() releases resources related to the cache. (Also its name is freed in kmem_cache_create_usercopy().) So IIUC current code works just fine! > > Signed-off-by: Xin Hao > --- > mm/slub.c | 7 +++---- > 1 file changed, 3 insertions(+), 4 deletions(-) > > diff --git a/mm/slub.c b/mm/slub.c > index b1281b8654bd..940a3f52e07c 100644 > --- a/mm/slub.c > +++ b/mm/slub.c > @@ -5981,19 +5981,18 @@ static int sysfs_slab_add(struct kmem_cache *s) > > err = sysfs_create_group(&s->kobj, &slab_attr_group); > if (err) > - goto out_del_kobj; > + goto out; > > if (!unmergeable) { > /* Setup first alias */ > sysfs_slab_alias(s, s->name); > } > + return err; > out: > if (!unmergeable) > kfree(name); > + kobject_put(&s->kobj); > return err; > -out_del_kobj: > - kobject_del(&s->kobj); So related resources are released in create_cache(), instead of by calling kobject_put(). But kobject_del() is still needed because it should unlink kobject hierarchy when kobject_add() succeeded but sysfs_create_group() failed! > - goto out; > } > > void sysfs_slab_unlink(struct kmem_cache *s) > -- > 2.31.0 > -- Thanks, Hyeonggon