Received: by 2002:a05:6a10:af89:0:0:0:0 with SMTP id iu9csp1361329pxb; Fri, 21 Jan 2022 16:31:25 -0800 (PST) X-Google-Smtp-Source: ABdhPJyL26HHMAF6b6RKaDg4Sl61U0hSrw5xy5Seg0W0wSKJwT+gouly3GWP88PUlaE4MZpiHMa0 X-Received: by 2002:a63:211a:: with SMTP id h26mr4499484pgh.239.1642811484911; Fri, 21 Jan 2022 16:31:24 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1642811484; cv=none; d=google.com; s=arc-20160816; b=u2RqRkdlgSZoHIRvhnfxDL3NZEpz8j4Q58f3bJIZVVK/bUqdXS0HfYcAhOpz4dcl1E xl7B5BMa7EQiOR5/4kl1hz5Jfo6vfco7xSAEs1ODEtCE24Rc6lgAIM6fkBu83skwxJZu C9JNf3tE7juCvJ/qOxPfIdMerUX1kHZO7FU6zsHcQMisQ+L22AiNsqPO/jfaGzdmREv9 g+xVPi+lgOJmIgXcfcCquk/eaXrdhyzCXBoBLjm+oSGL/FIcazFjiBElpE4jSFV2k2hR DZZmmq0Lvz79+rCrVSd/GvMbgfOAB6J3Ya0EB3SVwt+B0wGwc1fZHI73BcdS6H5N84Jl 8kew== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:cc:to:subject :message-id:date:from:in-reply-to:references:mime-version :dkim-signature; bh=9pfbFTwNFOqXDTrn460UZ4SRTCU9wK5Pp87Cp8WcchQ=; b=LjE2SAeRicKE1Eo7BFpia2Xy+wGO3BS6CwULLZklxUY8ZdRy49c6zWjjLK56xqu0Ya Kg/i2vQD6CAuPJfOJYDZy0vqcor3IsgTjZwWp9Mlfnf46DA6QTZ54inBQMV7sZbGGZ8y RZ/Vsxy7uWYop/hH18slyHgJV+ldLWEabSYzpyFWhRlN7X/LNRvyp3N8lXAw43t2ImeS PIRKWe+bd8/Doy+CeAOpMD82DZYLYxe6qV9yKNugEu6M8cFu8l2RKQuq8OPjrWzVWlii dmob8XfeST230FjA8CEEz1lgvsTmwzWxklxgilBbysueT8hVZlv0mqCrqijAzUSZGrxH g+sw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20210112 header.b=dnJghX5S; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id i69si2296399pge.619.2022.01.21.16.31.12; Fri, 21 Jan 2022 16:31:24 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20210112 header.b=dnJghX5S; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233628AbiAUDrz (ORCPT + 99 others); Thu, 20 Jan 2022 22:47:55 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:41692 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232662AbiAUDry (ORCPT ); Thu, 20 Jan 2022 22:47:54 -0500 Received: from mail-ed1-x52a.google.com (mail-ed1-x52a.google.com [IPv6:2a00:1450:4864:20::52a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 8D06CC061574; Thu, 20 Jan 2022 19:47:54 -0800 (PST) Received: by mail-ed1-x52a.google.com with SMTP id f21so37404554eds.11; Thu, 20 Jan 2022 19:47:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=9pfbFTwNFOqXDTrn460UZ4SRTCU9wK5Pp87Cp8WcchQ=; b=dnJghX5S5motNuQxvgJPOMnDkZD+vOuJ5IFIkIJpj0yUDXXoSJaohYJOzU9AH8ThJR 3bm4L7ANXW2Z0gQDvx9O67UUJ3jFoAqJ4zr5OaTnyZfXVIzSlmHMoIuxGzLUvunIC6sG AHqZYkHhFKfVURa4oemNwl5tVB/TXnYG6avUOwJGjJJTW9lVPE2FccpUqBu2rmp46HSs PApICazBeoq40F/Twm5SRogT+s9FCqtIQS9txE1Z8JI6OweiGwZnCNw/fWd0TpfX6Q2w h1j/8oOkYYi5RBPcW/tUoaMjQ/OnUUW809hIkbADdbx+8Jjc5BURA8E6GecrcirwvAA6 W6EA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=9pfbFTwNFOqXDTrn460UZ4SRTCU9wK5Pp87Cp8WcchQ=; b=eVZRaehoyvm8y0hzrlsrMkRwD7oMedQgII6poa0TuYolK854KsR/J0gcArhNuCVNlH x05zU7PEKpdI7FeoWluZ6bPXYl5m6ZGE2ErmgxwwqqFd1SAt0CV8+gdnC2g8Zpzfl5L4 XG75DW1a27FIDYYFHG3wVmaGR1vvl3vxzOroEnYPTCbM1hymhE+jIWr9fHM19jMBegcv p9Obh+UVwiUwr8Y9K8pslgSDf/VI1LGl2ZZaI6QZwVIsmY1YfaKsQUz30Hi54kfO01vR Curfzu0ZLVWrzlQda3S5tGI8LswDfho/RbpxmUuPnY3tr/p9LwCF/XHJ+qGMLHtF8szN Sf5w== X-Gm-Message-State: AOAM5320ivCx/d6bOelErZpsfiVm17Wi/wCzM/jZBqstVToNoJASTdjq FbHVZQ+bk0ME9lypfFnZw4Y+rxFlc6GZUU6JQEGfZmZSVCpjW+JK X-Received: by 2002:aa7:c243:: with SMTP id y3mr2429640edo.364.1642736873091; Thu, 20 Jan 2022 19:47:53 -0800 (PST) MIME-Version: 1.0 References: <3192BC90-D082-472B-B310-6E09A14A77C6@hust.edu.cn> In-Reply-To: <3192BC90-D082-472B-B310-6E09A14A77C6@hust.edu.cn> From: Dongliang Mu Date: Fri, 21 Jan 2022 11:47:26 +0800 Message-ID: Subject: Re: Fw:Re: [PATCH] fs: nilfs2: fix memory leak in nilfs sysfs create device group To: Pavel Skripkin , Andrew Morton , linux-nilfs , LKML , Nanyong Sun Cc: =?UTF-8?B?5oWV5Yas5Lqu?= Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > > From=EF=BC=9A Ryusuke Konishi > Date=EF=BC=9A 01/21/2022 01:54 > To=EF=BC=9A Dongliang Mu > Cc=EF=BC=9A Pavel Skripkin =E3=80=81 Andrew Morton= =E3=80=81 linux-nilfs =E3=80=81 LKML =E3=80=81 Nanyong Sun <= sunnanyong@huawei.com> > Subject=EF=BC=9A Re: [PATCH] fs: nilfs2: fix memory leak in nilfs_sysfs_c= reate_device_group > (added Nanyong Sun to CC) > Hi Dongliang, > > On Thu, Jan 20, 2022 at 11:07 PM Pavel Skripkin wr= ote: > > > Hi Dongliang, > > On 1/20/22 16:44, Dongliang Mu wrote: > > The preivous commit 8fd0c1b0647a ("nilfs2: fix memory leak in > nilfs_sysfs_delete_device_group") only handles the memory leak in the > nilfs_sysfs_delete_device_group. However, the similar memory leak still > occurs in the nilfs_sysfs_create_device_group. > > Fix it by adding kobject_del when > kobject_init_and_add succeeds, but one of the following calls fails. > > Fixes: 8fd0c1b0647a ("nilfs2: fix memory leak in nilfs_sysfs_delete_devic= e_group") > > > Why Fixes tag points to my commit? This issue was introduced before my pa= tch > > > As Pavel pointed out, this patch is independent of his patch. > The following one ? Hi Pavel, This is an incorrect fixes tag. I need to dig more about `git log -p fs/nilfs2/sysfs.c`. I wonder if there are any automatic or semi-automatic ways to capture this fixes tag. Or how do you guys identify the fixes tag? > > 5f5dec07aca7 ("nilfs2: fix memory leak in nilfs_sysfs_create_device_group= ") > > Signed-off-by: Dongliang Mu > --- > fs/nilfs2/sysfs.c | 5 ++++- > 1 file changed, 4 insertions(+), 1 deletion(-) > > > Can you describe what memory leak issue does this patch actually fix ? > > It looks like kobject_put() can call __kobject_del() unless circular > references exist. > > kobject_put() -> kref_put() -> kobject_release() -> > kobject_cleanup() -> __kobject_del() > > As explained in Documentation/core-api/kobject.rst, > > kobject_del() can be used to drop the reference to the parent object, if > circular references are constructed. > > But, at least, the parent object is NULL in this case. > I really want to understand what the real problem is. > > Thanks, > Ryusuke Konishi I know where my problem is. From the disconnect function, I think the kobject_del and kobject_put are both necessary without checking the documentation of kobjects. Then I think the current error handling may miss kobject_del, and this patch is generated. As a result, I think we can ignore this patch. Sorry for my false alarm. > > > diff --git a/fs/nilfs2/sysfs.c b/fs/nilfs2/sysfs.c > index 379d22e28ed6..0b2db2b499d5 100644 > --- a/fs/nilfs2/sysfs.c > +++ b/fs/nilfs2/sysfs.c > @@ -995,7 +995,7 @@ int nilfs_sysfs_create_device_group(struct super_bloc= k *sb) > > err =3D nilfs_sysfs_create_mounted_snapshots_group(nilfs); > if (err) > - goto cleanup_dev_kobject; > + goto delete_dev_kobject; > > err =3D nilfs_sysfs_create_checkpoints_group(nilfs); > if (err) > @@ -1027,6 +1027,9 @@ int nilfs_sysfs_create_device_group(struct super_bl= ock *sb) > delete_mounted_snapshots_group: > nilfs_sysfs_delete_mounted_snapshots_group(nilfs); > > +delete_dev_kobject: > + kobject_del(&nilfs->ns_dev_kobj); > + > cleanup_dev_kobject: > kobject_put(&nilfs->ns_dev_kobj); > kfree(nilfs->ns_dev_subgroups); > > With regards, > Pavel Skripkin