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 gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id B2DFCC433FE for ; Fri, 21 Oct 2022 13:08:48 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id B84EB10E279; Fri, 21 Oct 2022 13:08:44 +0000 (UTC) Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by gabe.freedesktop.org (Postfix) with ESMTPS id 60FAD10E491 for ; Fri, 21 Oct 2022 08:16:31 +0000 (UTC) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 6D8AF61DF6; Fri, 21 Oct 2022 08:16:29 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 512F7C433D7; Fri, 21 Oct 2022 08:16:28 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1666340188; bh=nDtywa6mieJPfGn7a73ycNgAHcz816CMD4ioaA/ZgqM=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=lO82TxFXbxQ1cn2DOqHCEKyNscPmKusZYKwJGtS1W9wHd/+uOdMexrwxM5m/eoZGP ixuN1pMyIVVKVRufxw1DnKqd7DCICC9i7tVNcPFmRr0aUFAthWwsrDgNS/LTSDl6lj lH2fmm/4fi6QX2qSDaq/NHngB7BNdQ/cZRRC7bts= Date: Fri, 21 Oct 2022 10:16:26 +0200 From: Greg KH To: Yang Yingliang Subject: Re: [PATCH 01/11] kset: fix documentation for kset_register() Message-ID: References: <20221021022102.2231464-1-yangyingliang@huawei.com> <20221021022102.2231464-2-yangyingliang@huawei.com> <10d887c4-7db0-8958-f661-bd52e6c8b4af@huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <10d887c4-7db0-8958-f661-bd52e6c8b4af@huawei.com> X-Mailman-Approved-At: Fri, 21 Oct 2022 13:08:22 +0000 X-BeenThere: amd-gfx@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion list for AMD gfx List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: rafael@kernel.org, qemu-devel@nongnu.org, liushixin2@huawei.com, joseph.qi@linux.alibaba.com, linux-mtd@lists.infradead.org, huangjianan@oppo.com, richard@nod.at, mark@fasheh.com, mst@redhat.com, amd-gfx@lists.freedesktop.org, Luben Tuikov , hsiangkao@linux.alibaba.com, somlo@cmu.edu, chao@kernel.org, jlbec@evilplan.org, jaegeuk@kernel.org, linux-kernel@vger.kernel.org, linux-f2fs-devel@lists.sourceforge.net, alexander.deucher@amd.com, akpm@linux-foundation.org, linux-erofs@lists.ozlabs.org, ocfs2-devel@oss.oracle.com Errors-To: amd-gfx-bounces@lists.freedesktop.org Sender: "amd-gfx" On Fri, Oct 21, 2022 at 04:05:18PM +0800, Yang Yingliang wrote: > > On 2022/10/21 13:34, Luben Tuikov wrote: > > On 2022-10-20 22:20, Yang Yingliang wrote: > > > kset_register() is currently used in some places without calling > > > kset_put() in error path, because the callers think it should be > > > kset internal thing to do, but the driver core can not know what > > > caller doing with that memory at times. The memory could be freed > > > both in kset_put() and error path of caller, if it is called in > > > kset_register(). > > > > > > So make the function documentation more explicit about calling > > > kset_put() in the error path of caller. > > > > > > Signed-off-by: Yang Yingliang > > > --- > > > lib/kobject.c | 3 +++ > > > 1 file changed, 3 insertions(+) > > > > > > diff --git a/lib/kobject.c b/lib/kobject.c > > > index a0b2dbfcfa23..6da04353d974 100644 > > > --- a/lib/kobject.c > > > +++ b/lib/kobject.c > > > @@ -834,6 +834,9 @@ EXPORT_SYMBOL_GPL(kobj_sysfs_ops); > > > /** > > > * kset_register() - Initialize and add a kset. > > > * @k: kset. > > > + * > > > + * If this function returns an error, kset_put() must be called to > > > + * properly clean up the memory associated with the object. > > > */ > > And I'd continue the sentence, with " ... with the object, > > for instance the memory for the kset.kobj.name when kobj_set_name(&kset.kobj, format, ...) > > was called before calling kset_register()." > kobject_cleanup() not only frees name, but aslo calls ->release() to free > another resources. Yes, but it's the kobject of the kset, which does need to have it's name cleaned up, but that kobject should NOT be freeing any larger structures that the kset might be embedded in, right? > > This makes it clear what we want to make sure is freed, in case of an early error > > from kset_register(). > > How about like this: > > If this function returns an error, kset_put() must be called to clean up the name of > kset object and other memory associated with the object. Again, I think we can fix this up to not be needed. thanks, greg k-h 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 lists.ozlabs.org (lists.ozlabs.org [112.213.38.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id B0B00C4332F for ; Fri, 21 Oct 2022 08:16:45 +0000 (UTC) Received: from boromir.ozlabs.org (localhost [IPv6:::1]) by lists.ozlabs.org (Postfix) with ESMTP id 4Mty3v6yy2z3dry for ; Fri, 21 Oct 2022 19:16:43 +1100 (AEDT) Authentication-Results: lists.ozlabs.org; dkim=fail reason="signature verification failed" (1024-bit key; unprotected) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.a=rsa-sha256 header.s=korg header.b=lO82TxFX; dkim-atps=neutral Authentication-Results: lists.ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=linuxfoundation.org (client-ip=2604:1380:4641:c500::1; helo=dfw.source.kernel.org; envelope-from=gregkh@linuxfoundation.org; receiver=) Authentication-Results: lists.ozlabs.org; dkim=pass (1024-bit key; unprotected) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.a=rsa-sha256 header.s=korg header.b=lO82TxFX; dkim-atps=neutral Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 4Mty3l06Ggz3bXn for ; Fri, 21 Oct 2022 19:16:34 +1100 (AEDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 6D8AF61DF6; Fri, 21 Oct 2022 08:16:29 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 512F7C433D7; Fri, 21 Oct 2022 08:16:28 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1666340188; bh=nDtywa6mieJPfGn7a73ycNgAHcz816CMD4ioaA/ZgqM=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=lO82TxFXbxQ1cn2DOqHCEKyNscPmKusZYKwJGtS1W9wHd/+uOdMexrwxM5m/eoZGP ixuN1pMyIVVKVRufxw1DnKqd7DCICC9i7tVNcPFmRr0aUFAthWwsrDgNS/LTSDl6lj lH2fmm/4fi6QX2qSDaq/NHngB7BNdQ/cZRRC7bts= Date: Fri, 21 Oct 2022 10:16:26 +0200 From: Greg KH To: Yang Yingliang Subject: Re: [PATCH 01/11] kset: fix documentation for kset_register() Message-ID: References: <20221021022102.2231464-1-yangyingliang@huawei.com> <20221021022102.2231464-2-yangyingliang@huawei.com> <10d887c4-7db0-8958-f661-bd52e6c8b4af@huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <10d887c4-7db0-8958-f661-bd52e6c8b4af@huawei.com> X-BeenThere: linux-erofs@lists.ozlabs.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Development of Linux EROFS file system List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: rafael@kernel.org, qemu-devel@nongnu.org, liushixin2@huawei.com, joseph.qi@linux.alibaba.com, linux-mtd@lists.infradead.org, huangjianan@oppo.com, richard@nod.at, mark@fasheh.com, mst@redhat.com, amd-gfx@lists.freedesktop.org, Luben Tuikov , hsiangkao@linux.alibaba.com, somlo@cmu.edu, jlbec@evilplan.org, jaegeuk@kernel.org, linux-kernel@vger.kernel.org, linux-f2fs-devel@lists.sourceforge.net, alexander.deucher@amd.com, akpm@linux-foundation.org, linux-erofs@lists.ozlabs.org, ocfs2-devel@oss.oracle.com Errors-To: linux-erofs-bounces+linux-erofs=archiver.kernel.org@lists.ozlabs.org Sender: "Linux-erofs" On Fri, Oct 21, 2022 at 04:05:18PM +0800, Yang Yingliang wrote: > > On 2022/10/21 13:34, Luben Tuikov wrote: > > On 2022-10-20 22:20, Yang Yingliang wrote: > > > kset_register() is currently used in some places without calling > > > kset_put() in error path, because the callers think it should be > > > kset internal thing to do, but the driver core can not know what > > > caller doing with that memory at times. The memory could be freed > > > both in kset_put() and error path of caller, if it is called in > > > kset_register(). > > > > > > So make the function documentation more explicit about calling > > > kset_put() in the error path of caller. > > > > > > Signed-off-by: Yang Yingliang > > > --- > > > lib/kobject.c | 3 +++ > > > 1 file changed, 3 insertions(+) > > > > > > diff --git a/lib/kobject.c b/lib/kobject.c > > > index a0b2dbfcfa23..6da04353d974 100644 > > > --- a/lib/kobject.c > > > +++ b/lib/kobject.c > > > @@ -834,6 +834,9 @@ EXPORT_SYMBOL_GPL(kobj_sysfs_ops); > > > /** > > > * kset_register() - Initialize and add a kset. > > > * @k: kset. > > > + * > > > + * If this function returns an error, kset_put() must be called to > > > + * properly clean up the memory associated with the object. > > > */ > > And I'd continue the sentence, with " ... with the object, > > for instance the memory for the kset.kobj.name when kobj_set_name(&kset.kobj, format, ...) > > was called before calling kset_register()." > kobject_cleanup() not only frees name, but aslo calls ->release() to free > another resources. Yes, but it's the kobject of the kset, which does need to have it's name cleaned up, but that kobject should NOT be freeing any larger structures that the kset might be embedded in, right? > > This makes it clear what we want to make sure is freed, in case of an early error > > from kset_register(). > > How about like this: > > If this function returns an error, kset_put() must be called to clean up the name of > kset object and other memory associated with the object. Again, I think we can fix this up to not be needed. thanks, greg k-h 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 lists.sourceforge.net (lists.sourceforge.net [216.105.38.7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 05557C4167D for ; Fri, 21 Oct 2022 08:16:49 +0000 (UTC) Received: from [127.0.0.1] (helo=sfs-ml-2.v29.lw.sourceforge.com) by sfs-ml-2.v29.lw.sourceforge.com with esmtp (Exim 4.95) (envelope-from ) id 1olnCy-0006Yx-8H; Fri, 21 Oct 2022 08:16:48 +0000 Received: from [172.30.20.202] (helo=mx.sourceforge.net) by sfs-ml-2.v29.lw.sourceforge.com with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.95) (envelope-from ) id 1olnCm-0006Yl-Ee for linux-f2fs-devel@lists.sourceforge.net; Fri, 21 Oct 2022 08:16:36 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sourceforge.net; s=x; h=In-Reply-To:Content-Type:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=Bv+xn0CYyTQsdUJdG42v0pWcxCKWbW+L5mfPqjTqsn4=; b=lPSshVyPKQEdgqJk9yw2AI10s5 ldNxtiwKcdQEO6/7VchR7+M8b3dibUv2f7aNzpGNNlEXIWb5RGPyjER7BFs9MD0Ntyv3oLeuTPhE2 Yeas2wlJbTqfkRd9j3uzLh8PLG7JCaQX58WsUD3fNzWY5wjl3JJw3rQzhEv9+XW+GwKM=; DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sf.net; s=x ; h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To :From:Date:Sender:Reply-To:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=Bv+xn0CYyTQsdUJdG42v0pWcxCKWbW+L5mfPqjTqsn4=; b=W3QPXW2sKbCtNKhvaMddY72dzt vh3tAglSSKLFQNumlzteWFzEDGiX8RUSw+J8O8vIaLgEFNrI2y4yXKRzR3IXv7HTKITievtPZajIy DEpvNxARnlR9xHmOEOOb9RmZaKrx7bAl+Fmfrsx/QBmFaoHx6xcDjcpKYx1h3aQAY14o=; Received: from dfw.source.kernel.org ([139.178.84.217]) by sfi-mx-2.v28.lw.sourceforge.com with esmtps (TLS1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.95) id 1olnCk-0000F4-VZ for linux-f2fs-devel@lists.sourceforge.net; Fri, 21 Oct 2022 08:16:36 +0000 Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 6D8AF61DF6; Fri, 21 Oct 2022 08:16:29 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 512F7C433D7; Fri, 21 Oct 2022 08:16:28 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1666340188; bh=nDtywa6mieJPfGn7a73ycNgAHcz816CMD4ioaA/ZgqM=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=lO82TxFXbxQ1cn2DOqHCEKyNscPmKusZYKwJGtS1W9wHd/+uOdMexrwxM5m/eoZGP ixuN1pMyIVVKVRufxw1DnKqd7DCICC9i7tVNcPFmRr0aUFAthWwsrDgNS/LTSDl6lj lH2fmm/4fi6QX2qSDaq/NHngB7BNdQ/cZRRC7bts= Date: Fri, 21 Oct 2022 10:16:26 +0200 From: Greg KH To: Yang Yingliang Message-ID: References: <20221021022102.2231464-1-yangyingliang@huawei.com> <20221021022102.2231464-2-yangyingliang@huawei.com> <10d887c4-7db0-8958-f661-bd52e6c8b4af@huawei.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <10d887c4-7db0-8958-f661-bd52e6c8b4af@huawei.com> X-Headers-End: 1olnCk-0000F4-VZ Subject: Re: [f2fs-dev] [PATCH 01/11] kset: fix documentation for kset_register() X-BeenThere: linux-f2fs-devel@lists.sourceforge.net X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: rafael@kernel.org, qemu-devel@nongnu.org, liushixin2@huawei.com, joseph.qi@linux.alibaba.com, linux-mtd@lists.infradead.org, richard@nod.at, mark@fasheh.com, mst@redhat.com, amd-gfx@lists.freedesktop.org, Luben Tuikov , hsiangkao@linux.alibaba.com, somlo@cmu.edu, jlbec@evilplan.org, jaegeuk@kernel.org, linux-kernel@vger.kernel.org, linux-f2fs-devel@lists.sourceforge.net, alexander.deucher@amd.com, akpm@linux-foundation.org, linux-erofs@lists.ozlabs.org, ocfs2-devel@oss.oracle.com Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: linux-f2fs-devel-bounces@lists.sourceforge.net On Fri, Oct 21, 2022 at 04:05:18PM +0800, Yang Yingliang wrote: > > On 2022/10/21 13:34, Luben Tuikov wrote: > > On 2022-10-20 22:20, Yang Yingliang wrote: > > > kset_register() is currently used in some places without calling > > > kset_put() in error path, because the callers think it should be > > > kset internal thing to do, but the driver core can not know what > > > caller doing with that memory at times. The memory could be freed > > > both in kset_put() and error path of caller, if it is called in > > > kset_register(). > > > > > > So make the function documentation more explicit about calling > > > kset_put() in the error path of caller. > > > > > > Signed-off-by: Yang Yingliang > > > --- > > > lib/kobject.c | 3 +++ > > > 1 file changed, 3 insertions(+) > > > > > > diff --git a/lib/kobject.c b/lib/kobject.c > > > index a0b2dbfcfa23..6da04353d974 100644 > > > --- a/lib/kobject.c > > > +++ b/lib/kobject.c > > > @@ -834,6 +834,9 @@ EXPORT_SYMBOL_GPL(kobj_sysfs_ops); > > > /** > > > * kset_register() - Initialize and add a kset. > > > * @k: kset. > > > + * > > > + * If this function returns an error, kset_put() must be called to > > > + * properly clean up the memory associated with the object. > > > */ > > And I'd continue the sentence, with " ... with the object, > > for instance the memory for the kset.kobj.name when kobj_set_name(&kset.kobj, format, ...) > > was called before calling kset_register()." > kobject_cleanup() not only frees name, but aslo calls ->release() to free > another resources. Yes, but it's the kobject of the kset, which does need to have it's name cleaned up, but that kobject should NOT be freeing any larger structures that the kset might be embedded in, right? > > This makes it clear what we want to make sure is freed, in case of an early error > > from kset_register(). > > How about like this: > > If this function returns an error, kset_put() must be called to clean up the name of > kset object and other memory associated with the object. Again, I think we can fix this up to not be needed. thanks, greg k-h _______________________________________________ Linux-f2fs-devel mailing list Linux-f2fs-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel 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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id A5DFBC4332F for ; Fri, 21 Oct 2022 08:17:05 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=NAYA0iaKRLpoXwAUNsVbRjvbsL4g9XSkhmCEo83R8hM=; b=HF9KwHZvfFxybN 0OQRmLtdCc7xKEncqf5NJcCLJxZZIFBnt7GFtoePtNXdpgnKbWNkTF8uq/t9UodcdQ5MMuVIVzNTF 6Jn07OPwOLTqe/eT898o33E5jL97aOVieiLxEiNb7qowuXgBFjqyeAVYV1SmpmoyxUgLbQ5m9111q dtFPGKwsRwEh/XkjQUyAIFMwy8miHzKRKjMfv/nbnrdf4IgF+2vHG30S8eqf3U7RaQIj5EsMzgocJ mQLUsSg1yLZd4vkwiAwSD1D/VwYGkgy8TiTEiN/d7LAB9J2Xf0o9ulMvc+RE+nlJdEOU7SJsQDOIF 7hWoaWhvNOPKHXmY5wgw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1olnCk-006HHM-79; Fri, 21 Oct 2022 08:16:34 +0000 Received: from dfw.source.kernel.org ([139.178.84.217]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1olnCg-006HEP-Pw for linux-mtd@lists.infradead.org; Fri, 21 Oct 2022 08:16:32 +0000 Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 6D8AF61DF6; Fri, 21 Oct 2022 08:16:29 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 512F7C433D7; Fri, 21 Oct 2022 08:16:28 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1666340188; bh=nDtywa6mieJPfGn7a73ycNgAHcz816CMD4ioaA/ZgqM=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=lO82TxFXbxQ1cn2DOqHCEKyNscPmKusZYKwJGtS1W9wHd/+uOdMexrwxM5m/eoZGP ixuN1pMyIVVKVRufxw1DnKqd7DCICC9i7tVNcPFmRr0aUFAthWwsrDgNS/LTSDl6lj lH2fmm/4fi6QX2qSDaq/NHngB7BNdQ/cZRRC7bts= Date: Fri, 21 Oct 2022 10:16:26 +0200 From: Greg KH To: Yang Yingliang Cc: Luben Tuikov , linux-kernel@vger.kernel.org, qemu-devel@nongnu.org, linux-f2fs-devel@lists.sourceforge.net, linux-erofs@lists.ozlabs.org, ocfs2-devel@oss.oracle.com, linux-mtd@lists.infradead.org, amd-gfx@lists.freedesktop.org, rafael@kernel.org, somlo@cmu.edu, mst@redhat.com, jaegeuk@kernel.org, chao@kernel.org, hsiangkao@linux.alibaba.com, huangjianan@oppo.com, mark@fasheh.com, jlbec@evilplan.org, joseph.qi@linux.alibaba.com, akpm@linux-foundation.org, alexander.deucher@amd.com, richard@nod.at, liushixin2@huawei.com Subject: Re: [PATCH 01/11] kset: fix documentation for kset_register() Message-ID: References: <20221021022102.2231464-1-yangyingliang@huawei.com> <20221021022102.2231464-2-yangyingliang@huawei.com> <10d887c4-7db0-8958-f661-bd52e6c8b4af@huawei.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <10d887c4-7db0-8958-f661-bd52e6c8b4af@huawei.com> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20221021_011630_948768_D487BFDC X-CRM114-Status: GOOD ( 30.17 ) X-BeenThere: linux-mtd@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Linux MTD discussion mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-mtd" Errors-To: linux-mtd-bounces+linux-mtd=archiver.kernel.org@lists.infradead.org On Fri, Oct 21, 2022 at 04:05:18PM +0800, Yang Yingliang wrote: > > On 2022/10/21 13:34, Luben Tuikov wrote: > > On 2022-10-20 22:20, Yang Yingliang wrote: > > > kset_register() is currently used in some places without calling > > > kset_put() in error path, because the callers think it should be > > > kset internal thing to do, but the driver core can not know what > > > caller doing with that memory at times. The memory could be freed > > > both in kset_put() and error path of caller, if it is called in > > > kset_register(). > > > > > > So make the function documentation more explicit about calling > > > kset_put() in the error path of caller. > > > > > > Signed-off-by: Yang Yingliang > > > --- > > > lib/kobject.c | 3 +++ > > > 1 file changed, 3 insertions(+) > > > > > > diff --git a/lib/kobject.c b/lib/kobject.c > > > index a0b2dbfcfa23..6da04353d974 100644 > > > --- a/lib/kobject.c > > > +++ b/lib/kobject.c > > > @@ -834,6 +834,9 @@ EXPORT_SYMBOL_GPL(kobj_sysfs_ops); > > > /** > > > * kset_register() - Initialize and add a kset. > > > * @k: kset. > > > + * > > > + * If this function returns an error, kset_put() must be called to > > > + * properly clean up the memory associated with the object. > > > */ > > And I'd continue the sentence, with " ... with the object, > > for instance the memory for the kset.kobj.name when kobj_set_name(&kset.kobj, format, ...) > > was called before calling kset_register()." > kobject_cleanup() not only frees name, but aslo calls ->release() to free > another resources. Yes, but it's the kobject of the kset, which does need to have it's name cleaned up, but that kobject should NOT be freeing any larger structures that the kset might be embedded in, right? > > This makes it clear what we want to make sure is freed, in case of an early error > > from kset_register(). > > How about like this: > > If this function returns an error, kset_put() must be called to clean up the name of > kset object and other memory associated with the object. Again, I think we can fix this up to not be needed. thanks, greg k-h ______________________________________________________ Linux MTD discussion mailing list http://lists.infradead.org/mailman/listinfo/linux-mtd/ 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 aib29ajc255.phx1.oracleemaildelivery.com (aib29ajc255.phx1.oracleemaildelivery.com [192.29.103.255]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id C95CDC433FE for ; Fri, 21 Oct 2022 08:16:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; s=oss-phx-1109; d=oss.oracle.com; h=Date:To:From:Subject:Message-Id:MIME-Version:Sender; bh=d0JlSwEf8zNE0BXvTSRGUyoUHWpbzjx8BhTw7G18Ovw=; b=iYs2SSTs9HRVmYW9X/7Gr3HreIqKlgqOQ5Ec6VolWGXoeYjKx1Ns6jYgroAZKO/gDbteK4wrkF82 SE7VS0QxSK8D5jk2hb5Fz0rtEZSrZs1XJGQxn4Q4coAalDtM+PMDzqL/94l00q37MxvwRF7Wr/oX rpVxCI/VchuP8HrTLqeI8iPAiq2sV48gY9EWdE55uH/WeWxg5NUKgN0T07uOYC+Dv2oyOBe0uqSd Tf8Pdz3lb/t4/WBnf/MlTQwSqrKZmUu+xmh4Vwv656AaDhlEvzeLeUM89Jjg5GIt4H+arrbh7fTE 8p0Gk+iVwcTA+k7+h5sPZ8ga4F5ADRIe1GP5ug== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; s=prod-phx-20191217; d=phx1.rp.oracleemaildelivery.com; h=Date:To:From:Subject:Message-Id:MIME-Version:Sender; bh=d0JlSwEf8zNE0BXvTSRGUyoUHWpbzjx8BhTw7G18Ovw=; b=Vbtx0xDSEnJd4jXkyI1VZ0kPaOmhMsn9R3O/hRf+xyK1Y0uTuMfTUMEzwxHGvJqSe8yw6oOoMvf0 DYMS/vMkxohGKVskalzAHpGc6akxcWfyDNZrYjJLmBse1u447MI33hNQgk9rVaIVrKnMv15vduN5 hJe4Pl3B8fKLgImETwWHVZYUHTSf04Q67iCvNvvfWnjcVdbgRxUBhTbvSEF9fDgNIbZsO99G1IRo FiCb4UHneBOUHCizXUdICwO5f5Ilp3+40vE/626BitA+tCKXKAfoudPY7P2wybZO6i3RucjJLxW9 oH7chiqZPzpflNg1WbBdgw/KEb3bdhJRLdrPSw== Received: by omta-ad3-fd3-302-us-phoenix-1.omtaad3.vcndpphx.oraclevcn.com (Oracle Communications Messaging Server 8.1.0.1.20220914 64bit (built Sep 14 2022)) with ESMTPS id <0RK300AFAGBVZ090@omta-ad3-fd3-302-us-phoenix-1.omtaad3.vcndpphx.oraclevcn.com> for ocfs2-devel@archiver.kernel.org; Fri, 21 Oct 2022 08:16:43 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1666340188; bh=nDtywa6mieJPfGn7a73ycNgAHcz816CMD4ioaA/ZgqM=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=lO82TxFXbxQ1cn2DOqHCEKyNscPmKusZYKwJGtS1W9wHd/+uOdMexrwxM5m/eoZGP ixuN1pMyIVVKVRufxw1DnKqd7DCICC9i7tVNcPFmRr0aUFAthWwsrDgNS/LTSDl6lj lH2fmm/4fi6QX2qSDaq/NHngB7BNdQ/cZRRC7bts= Date: Fri, 21 Oct 2022 10:16:26 +0200 To: Yang Yingliang Message-id: References: <20221021022102.2231464-1-yangyingliang@huawei.com> <20221021022102.2231464-2-yangyingliang@huawei.com> <10d887c4-7db0-8958-f661-bd52e6c8b4af@huawei.com> MIME-version: 1.0 Content-disposition: inline In-reply-to: <10d887c4-7db0-8958-f661-bd52e6c8b4af@huawei.com> X-Source-IP: 139.178.84.217 X-Proofpoint-Virus-Version: vendor=nai engine=6500 definitions=10506 signatures=596816 X-Proofpoint-Spam-Details: rule=tap_notspam policy=tap score=0 spamscore=0 priorityscore=382 impostorscore=0 malwarescore=0 phishscore=0 suspectscore=0 adultscore=0 clxscore=145 mlxlogscore=743 bulkscore=0 mlxscore=0 lowpriorityscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2209130000 definitions=main-2210210048 Cc: rafael@kernel.org, qemu-devel@nongnu.org, liushixin2@huawei.com, linux-mtd@lists.infradead.org, huangjianan@oppo.com, richard@nod.at, mst@redhat.com, amd-gfx@lists.freedesktop.org, Luben Tuikov , hsiangkao@linux.alibaba.com, somlo@cmu.edu, chao@kernel.org, jaegeuk@kernel.org, linux-kernel@vger.kernel.org, linux-f2fs-devel@lists.sourceforge.net, alexander.deucher@amd.com, linux-erofs@lists.ozlabs.org, ocfs2-devel@oss.oracle.com Subject: Re: [Ocfs2-devel] [PATCH 01/11] kset: fix documentation for kset_register() X-BeenThere: ocfs2-devel@oss.oracle.com X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Greg KH via Ocfs2-devel Reply-to: Greg KH Content-type: text/plain; charset="us-ascii" Content-transfer-encoding: 7bit Errors-to: ocfs2-devel-bounces@oss.oracle.com X-ServerName: dfw.source.kernel.org X-Proofpoint-SPF-Result: pass X-Proofpoint-SPF-Record: v=spf1 ip4:72.55.140.81 ip4:52.25.139.140 ip4:139.178.84.217 ip6:2604:1380:4641:c500::1 ip4:145.40.68.75 ip6:2604:1380:4601:e00::1 ip4:145.40.73.55 ip6:2604:1380:40e1:4800::1 include:_spf.google.com include:amazonses.com include:_spf.salesforce.com -all X-Spam: Clean X-Proofpoint-ORIG-GUID: nHXUqGK3aDaHCMlMKdejY0iKo5L4P9F2 X-Proofpoint-GUID: nHXUqGK3aDaHCMlMKdejY0iKo5L4P9F2 Reporting-Meta: AAFk9+RxUNFyP4Rxhht/iTqc3EUPZKy9oHRzsiJMQUU2VQvHl3w8SngHLVySStIh OT8LJYJ6cl5+CuI0zLuzMwQTIbu5H42d+zjJ0vo68qYNX+4UBpTH6FF8uw2ipNSy 6Db1fI4O896MWrCtJ3dQFVMrDQnFzPq6wa1HmR8oTv5bK8mX83p//0Cr88FfUPOA QHW1kRlnd9m6dPUpwzAdOp9kG5cCFh7TthDFio3+siksJJnlQ+SFiKAbz/9Y/Rxo whSN744DcY+LwfwNLDUV74GKfvsjiGF7KwGg+pPxVbEyWRXor67TMsKvY/69l/x7 LG/YmHp7RCcmRHune/7yGDRpsQ82heKIT93bixc3cAQUnb32eqFcJn1/NbNhAfc4 4XWoFK0zqpr3EL+HiC/rVKC1G9sjRrRzj5vKknQdZndOCHgtwiVQxLNi+3YxXsne GTszINbYL2UGC0cxfJVXfkATO6naXWLcFMlLfQCMDiQparbyLprqsT7NODvFRCfy zsmO3oekFXRIpjyfPbw21wiV3tKQgjQzW+pOKEgbhhCf On Fri, Oct 21, 2022 at 04:05:18PM +0800, Yang Yingliang wrote: > > On 2022/10/21 13:34, Luben Tuikov wrote: > > On 2022-10-20 22:20, Yang Yingliang wrote: > > > kset_register() is currently used in some places without calling > > > kset_put() in error path, because the callers think it should be > > > kset internal thing to do, but the driver core can not know what > > > caller doing with that memory at times. The memory could be freed > > > both in kset_put() and error path of caller, if it is called in > > > kset_register(). > > > > > > So make the function documentation more explicit about calling > > > kset_put() in the error path of caller. > > > > > > Signed-off-by: Yang Yingliang > > > --- > > > lib/kobject.c | 3 +++ > > > 1 file changed, 3 insertions(+) > > > > > > diff --git a/lib/kobject.c b/lib/kobject.c > > > index a0b2dbfcfa23..6da04353d974 100644 > > > --- a/lib/kobject.c > > > +++ b/lib/kobject.c > > > @@ -834,6 +834,9 @@ EXPORT_SYMBOL_GPL(kobj_sysfs_ops); > > > /** > > > * kset_register() - Initialize and add a kset. > > > * @k: kset. > > > + * > > > + * If this function returns an error, kset_put() must be called to > > > + * properly clean up the memory associated with the object. > > > */ > > And I'd continue the sentence, with " ... with the object, > > for instance the memory for the kset.kobj.name when kobj_set_name(&kset.kobj, format, ...) > > was called before calling kset_register()." > kobject_cleanup() not only frees name, but aslo calls ->release() to free > another resources. Yes, but it's the kobject of the kset, which does need to have it's name cleaned up, but that kobject should NOT be freeing any larger structures that the kset might be embedded in, right? > > This makes it clear what we want to make sure is freed, in case of an early error > > from kset_register(). > > How about like this: > > If this function returns an error, kset_put() must be called to clean up the name of > kset object and other memory associated with the object. Again, I think we can fix this up to not be needed. thanks, greg k-h _______________________________________________ Ocfs2-devel mailing list Ocfs2-devel@oss.oracle.com https://oss.oracle.com/mailman/listinfo/ocfs2-devel 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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id AE550C433FE for ; Fri, 21 Oct 2022 08:16:51 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230078AbiJUIQt (ORCPT ); Fri, 21 Oct 2022 04:16:49 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45114 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229740AbiJUIQp (ORCPT ); Fri, 21 Oct 2022 04:16:45 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 59AE41EA573 for ; Fri, 21 Oct 2022 01:16:31 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 2A851B82B63 for ; Fri, 21 Oct 2022 08:16:30 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 512F7C433D7; Fri, 21 Oct 2022 08:16:28 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1666340188; bh=nDtywa6mieJPfGn7a73ycNgAHcz816CMD4ioaA/ZgqM=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=lO82TxFXbxQ1cn2DOqHCEKyNscPmKusZYKwJGtS1W9wHd/+uOdMexrwxM5m/eoZGP ixuN1pMyIVVKVRufxw1DnKqd7DCICC9i7tVNcPFmRr0aUFAthWwsrDgNS/LTSDl6lj lH2fmm/4fi6QX2qSDaq/NHngB7BNdQ/cZRRC7bts= Date: Fri, 21 Oct 2022 10:16:26 +0200 From: Greg KH To: Yang Yingliang Cc: Luben Tuikov , linux-kernel@vger.kernel.org, qemu-devel@nongnu.org, linux-f2fs-devel@lists.sourceforge.net, linux-erofs@lists.ozlabs.org, ocfs2-devel@oss.oracle.com, linux-mtd@lists.infradead.org, amd-gfx@lists.freedesktop.org, rafael@kernel.org, somlo@cmu.edu, mst@redhat.com, jaegeuk@kernel.org, chao@kernel.org, hsiangkao@linux.alibaba.com, huangjianan@oppo.com, mark@fasheh.com, jlbec@evilplan.org, joseph.qi@linux.alibaba.com, akpm@linux-foundation.org, alexander.deucher@amd.com, richard@nod.at, liushixin2@huawei.com Subject: Re: [PATCH 01/11] kset: fix documentation for kset_register() Message-ID: References: <20221021022102.2231464-1-yangyingliang@huawei.com> <20221021022102.2231464-2-yangyingliang@huawei.com> <10d887c4-7db0-8958-f661-bd52e6c8b4af@huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <10d887c4-7db0-8958-f661-bd52e6c8b4af@huawei.com> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Oct 21, 2022 at 04:05:18PM +0800, Yang Yingliang wrote: > > On 2022/10/21 13:34, Luben Tuikov wrote: > > On 2022-10-20 22:20, Yang Yingliang wrote: > > > kset_register() is currently used in some places without calling > > > kset_put() in error path, because the callers think it should be > > > kset internal thing to do, but the driver core can not know what > > > caller doing with that memory at times. The memory could be freed > > > both in kset_put() and error path of caller, if it is called in > > > kset_register(). > > > > > > So make the function documentation more explicit about calling > > > kset_put() in the error path of caller. > > > > > > Signed-off-by: Yang Yingliang > > > --- > > > lib/kobject.c | 3 +++ > > > 1 file changed, 3 insertions(+) > > > > > > diff --git a/lib/kobject.c b/lib/kobject.c > > > index a0b2dbfcfa23..6da04353d974 100644 > > > --- a/lib/kobject.c > > > +++ b/lib/kobject.c > > > @@ -834,6 +834,9 @@ EXPORT_SYMBOL_GPL(kobj_sysfs_ops); > > > /** > > > * kset_register() - Initialize and add a kset. > > > * @k: kset. > > > + * > > > + * If this function returns an error, kset_put() must be called to > > > + * properly clean up the memory associated with the object. > > > */ > > And I'd continue the sentence, with " ... with the object, > > for instance the memory for the kset.kobj.name when kobj_set_name(&kset.kobj, format, ...) > > was called before calling kset_register()." > kobject_cleanup() not only frees name, but aslo calls ->release() to free > another resources. Yes, but it's the kobject of the kset, which does need to have it's name cleaned up, but that kobject should NOT be freeing any larger structures that the kset might be embedded in, right? > > This makes it clear what we want to make sure is freed, in case of an early error > > from kset_register(). > > How about like this: > > If this function returns an error, kset_put() must be called to clean up the name of > kset object and other memory associated with the object. Again, I think we can fix this up to not be needed. thanks, greg k-h