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 B4C17C4332F for ; Fri, 21 Oct 2022 13:08:51 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 2E8D110E281; Fri, 21 Oct 2022 13:08:46 +0000 (UTC) Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by gabe.freedesktop.org (Postfix) with ESMTPS id 4056810E642 for ; Fri, 21 Oct 2022 08:36:10 +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 ams.source.kernel.org (Postfix) with ESMTPS id 95B30B82B63; Fri, 21 Oct 2022 08:36:08 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id C57E2C433D6; Fri, 21 Oct 2022 08:36:06 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1666341367; bh=VYkxOdyqZTRP94uFOMrKlhrYPkv6+oVeaJOCigiokeE=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=0LHArjuO/emmogeedg4sidpH81EIC1oFajIQk20rr9Km/Y0ewObOQB0i43jXid6V8 MEWVl4mxIE2auEWLdOFh5S0zN7a5cdswL8kZv1F5sHrcBCX+9z8wc+kpjX8Czr8S07 DVGuTf4yxBxOxcpimxvN26SCCFuV+ZffgRv7I1WQ= Date: Fri, 21 Oct 2022 10:36:04 +0200 From: Greg KH To: Yang Yingliang Subject: Re: [PATCH 00/11] fix memory leak while kset_register() fails Message-ID: References: <20221021022102.2231464-1-yangyingliang@huawei.com> <0591e66f-731a-5f81-fc9d-3a6d80516c65@huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <0591e66f-731a-5f81-fc9d-3a6d80516c65@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:24:23PM +0800, Yang Yingliang wrote: > > On 2022/10/21 13:37, Greg KH wrote: > > On Fri, Oct 21, 2022 at 01:29:31AM -0400, Luben Tuikov wrote: > > > On 2022-10-20 22:20, Yang Yingliang wrote: > > > > The previous discussion link: > > > > https://lore.kernel.org/lkml/0db486eb-6927-927e-3629-958f8f211194@huawei.com/T/ > > > The very first discussion on this was here: > > > > > > https://www.spinics.net/lists/dri-devel/msg368077.html > > > > > > Please use this link, and not the that one up there you which quoted above, > > > and whose commit description is taken verbatim from the this link. > > > > > > > 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(). > > > As I explained in the link above, the reason there's > > > a memory leak is that one cannot call kset_register() without > > > the kset->kobj.name being set--kobj_add_internal() returns -EINVAL, > > > in this case, i.e. kset_register() fails with -EINVAL. > > > > > > Thus, the most common usage is something like this: > > > > > > kobj_set_name(&kset->kobj, format, ...); > > > kset->kobj.kset = parent_kset; > > > kset->kobj.ktype = ktype; > > > res = kset_register(kset); > > > > > > So, what is being leaked, is the memory allocated in kobj_set_name(), > > > by the common idiom shown above. This needs to be mentioned in > > > the documentation, at least, in case, in the future this is absolved > > > in kset_register() redesign, etc. > > Based on this, can kset_register() just clean up from itself when an > > error happens? Ideally that would be the case, as the odds of a kset > > being embedded in a larger structure is probably slim, but we would have > > to search the tree to make sure. > I have search the whole tree, the kset used in bus_register() - patch #3, > kset_create_and_add() - patch #4 > __class_register() - patch #5,  fw_cfg_build_symlink() - patch #6 and > amdgpu_discovery.c - patch #10 > is embedded in a larger structure. In these cases, we can not call > kset_put() in error path in kset_register() Yes you can as the kobject in the kset should NOT be controling the lifespan of those larger objects. If it is, please point out the call chain here as I don't think that should be possible. Note all of this is a mess because the kobject name stuff was added much later, after the driver model had been created and running for a while. We missed this error path when adding the dynamic kobject name logic, thank for looking into this. If you could test the patch posted with your error injection systems, that could make this all much simpler to solve. 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 EED90C433FE for ; Fri, 21 Oct 2022 08:36:20 +0000 (UTC) Received: from boromir.ozlabs.org (localhost [IPv6:::1]) by lists.ozlabs.org (Postfix) with ESMTP id 4MtyVW2f66z3ds2 for ; Fri, 21 Oct 2022 19:36:19 +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=0LHArjuO; dkim-atps=neutral Authentication-Results: lists.ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=linuxfoundation.org (client-ip=2604:1380:4601:e00::1; helo=ams.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=0LHArjuO; dkim-atps=neutral Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::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 4MtyVM3Tvsz3bXn for ; Fri, 21 Oct 2022 19:36:11 +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 ams.source.kernel.org (Postfix) with ESMTPS id 95B30B82B63; Fri, 21 Oct 2022 08:36:08 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id C57E2C433D6; Fri, 21 Oct 2022 08:36:06 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1666341367; bh=VYkxOdyqZTRP94uFOMrKlhrYPkv6+oVeaJOCigiokeE=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=0LHArjuO/emmogeedg4sidpH81EIC1oFajIQk20rr9Km/Y0ewObOQB0i43jXid6V8 MEWVl4mxIE2auEWLdOFh5S0zN7a5cdswL8kZv1F5sHrcBCX+9z8wc+kpjX8Czr8S07 DVGuTf4yxBxOxcpimxvN26SCCFuV+ZffgRv7I1WQ= Date: Fri, 21 Oct 2022 10:36:04 +0200 From: Greg KH To: Yang Yingliang Subject: Re: [PATCH 00/11] fix memory leak while kset_register() fails Message-ID: References: <20221021022102.2231464-1-yangyingliang@huawei.com> <0591e66f-731a-5f81-fc9d-3a6d80516c65@huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <0591e66f-731a-5f81-fc9d-3a6d80516c65@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:24:23PM +0800, Yang Yingliang wrote: > > On 2022/10/21 13:37, Greg KH wrote: > > On Fri, Oct 21, 2022 at 01:29:31AM -0400, Luben Tuikov wrote: > > > On 2022-10-20 22:20, Yang Yingliang wrote: > > > > The previous discussion link: > > > > https://lore.kernel.org/lkml/0db486eb-6927-927e-3629-958f8f211194@huawei.com/T/ > > > The very first discussion on this was here: > > > > > > https://www.spinics.net/lists/dri-devel/msg368077.html > > > > > > Please use this link, and not the that one up there you which quoted above, > > > and whose commit description is taken verbatim from the this link. > > > > > > > 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(). > > > As I explained in the link above, the reason there's > > > a memory leak is that one cannot call kset_register() without > > > the kset->kobj.name being set--kobj_add_internal() returns -EINVAL, > > > in this case, i.e. kset_register() fails with -EINVAL. > > > > > > Thus, the most common usage is something like this: > > > > > > kobj_set_name(&kset->kobj, format, ...); > > > kset->kobj.kset = parent_kset; > > > kset->kobj.ktype = ktype; > > > res = kset_register(kset); > > > > > > So, what is being leaked, is the memory allocated in kobj_set_name(), > > > by the common idiom shown above. This needs to be mentioned in > > > the documentation, at least, in case, in the future this is absolved > > > in kset_register() redesign, etc. > > Based on this, can kset_register() just clean up from itself when an > > error happens? Ideally that would be the case, as the odds of a kset > > being embedded in a larger structure is probably slim, but we would have > > to search the tree to make sure. > I have search the whole tree, the kset used in bus_register() - patch #3, > kset_create_and_add() - patch #4 > __class_register() - patch #5,  fw_cfg_build_symlink() - patch #6 and > amdgpu_discovery.c - patch #10 > is embedded in a larger structure. In these cases, we can not call > kset_put() in error path in kset_register() Yes you can as the kobject in the kset should NOT be controling the lifespan of those larger objects. If it is, please point out the call chain here as I don't think that should be possible. Note all of this is a mess because the kobject name stuff was added much later, after the driver model had been created and running for a while. We missed this error path when adding the dynamic kobject name logic, thank for looking into this. If you could test the patch posted with your error injection systems, that could make this all much simpler to solve. 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 DB633C43219 for ; Fri, 21 Oct 2022 08:36:26 +0000 (UTC) Received: from [127.0.0.1] (helo=sfs-ml-4.v29.lw.sourceforge.com) by sfs-ml-4.v29.lw.sourceforge.com with esmtp (Exim 4.95) (envelope-from ) id 1olnVx-00006S-Ob; Fri, 21 Oct 2022 08:36:25 +0000 Received: from [172.30.20.202] (helo=mx.sourceforge.net) by sfs-ml-4.v29.lw.sourceforge.com with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.95) (envelope-from ) id 1olnVw-00006M-O0 for linux-f2fs-devel@lists.sourceforge.net; Fri, 21 Oct 2022 08:36:24 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sourceforge.net; s=x; h=In-Reply-To:Content-Transfer-Encoding:Content-Type: MIME-Version:References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: 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=t1YS74Nvk7oCxM1pKvXyLB5PZcp3CtEHrUYkNo4yhow=; b=Lo6vL+Rz7OuEcODlXPYekjTPX1 bTF+MlG9OVqwYs1GcnVG0sxYmHDm1DN8nHZ5PiXLuHkFJflJWWZ8ZM5DNboTLhHEz8BIkHJsvE70M bjwvcPA10ZY8NwmxlUkJbxDNKaFU2rdqNUCPg2GcixGWap2Udv8oMIoWQ8sOOmUR5bcY=; DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sf.net; s=x ; h=In-Reply-To:Content-Transfer-Encoding:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: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=t1YS74Nvk7oCxM1pKvXyLB5PZcp3CtEHrUYkNo4yhow=; b=NRZBif5zh2546zIo6PRrdKCxqJ v+TAna4zswFemZFWAmoq700ieYvUSpFwrdX4x1DLlBSpJoYGcB0jDh5XUYXvRmoXO4poKMp6BgxUb SmO6QvkQ/BrthNnvW5cmoMk21SV6UGIZ7qHSRZWMMDC2H5uctiwU7BxQLOlqSDwS5PIc=; Received: from ams.source.kernel.org ([145.40.68.75]) by sfi-mx-1.v28.lw.sourceforge.com with esmtps (TLS1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.95) id 1olnVs-00C3vF-JU for linux-f2fs-devel@lists.sourceforge.net; Fri, 21 Oct 2022 08:36:24 +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 ams.source.kernel.org (Postfix) with ESMTPS id 95B30B82B63; Fri, 21 Oct 2022 08:36:08 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id C57E2C433D6; Fri, 21 Oct 2022 08:36:06 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1666341367; bh=VYkxOdyqZTRP94uFOMrKlhrYPkv6+oVeaJOCigiokeE=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=0LHArjuO/emmogeedg4sidpH81EIC1oFajIQk20rr9Km/Y0ewObOQB0i43jXid6V8 MEWVl4mxIE2auEWLdOFh5S0zN7a5cdswL8kZv1F5sHrcBCX+9z8wc+kpjX8Czr8S07 DVGuTf4yxBxOxcpimxvN26SCCFuV+ZffgRv7I1WQ= Date: Fri, 21 Oct 2022 10:36:04 +0200 From: Greg KH To: Yang Yingliang Message-ID: References: <20221021022102.2231464-1-yangyingliang@huawei.com> <0591e66f-731a-5f81-fc9d-3a6d80516c65@huawei.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <0591e66f-731a-5f81-fc9d-3a6d80516c65@huawei.com> X-Headers-End: 1olnVs-00C3vF-JU Subject: Re: [f2fs-dev] [PATCH 00/11] fix memory leak while kset_register() fails 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Errors-To: linux-f2fs-devel-bounces@lists.sourceforge.net On Fri, Oct 21, 2022 at 04:24:23PM +0800, Yang Yingliang wrote: > = > On 2022/10/21 13:37, Greg KH wrote: > > On Fri, Oct 21, 2022 at 01:29:31AM -0400, Luben Tuikov wrote: > > > On 2022-10-20 22:20, Yang Yingliang wrote: > > > > The previous discussion link: > > > > https://lore.kernel.org/lkml/0db486eb-6927-927e-3629-958f8f211194@h= uawei.com/T/ > > > The very first discussion on this was here: > > > = > > > https://www.spinics.net/lists/dri-devel/msg368077.html > > > = > > > Please use this link, and not the that one up there you which quoted = above, > > > and whose commit description is taken verbatim from the this link. > > > = > > > > 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(). > > > As I explained in the link above, the reason there's > > > a memory leak is that one cannot call kset_register() without > > > the kset->kobj.name being set--kobj_add_internal() returns -EINVAL, > > > in this case, i.e. kset_register() fails with -EINVAL. > > > = > > > Thus, the most common usage is something like this: > > > = > > > kobj_set_name(&kset->kobj, format, ...); > > > kset->kobj.kset =3D parent_kset; > > > kset->kobj.ktype =3D ktype; > > > res =3D kset_register(kset); > > > = > > > So, what is being leaked, is the memory allocated in kobj_set_name(), > > > by the common idiom shown above. This needs to be mentioned in > > > the documentation, at least, in case, in the future this is absolved > > > in kset_register() redesign, etc. > > Based on this, can kset_register() just clean up from itself when an > > error happens? Ideally that would be the case, as the odds of a kset > > being embedded in a larger structure is probably slim, but we would have > > to search the tree to make sure. > I have search the whole tree, the kset used in bus_register() - patch #3, > kset_create_and_add() - patch #4 > __class_register() - patch #5,=A0 fw_cfg_build_symlink() - patch #6 and > amdgpu_discovery.c - patch #10 > is embedded in a larger structure. In these cases, we can not call > kset_put() in error path in kset_register() Yes you can as the kobject in the kset should NOT be controling the lifespan of those larger objects. If it is, please point out the call chain here as I don't think that should be possible. Note all of this is a mess because the kobject name stuff was added much later, after the driver model had been created and running for a while. We missed this error path when adding the dynamic kobject name logic, thank for looking into this. If you could test the patch posted with your error injection systems, that could make this all much simpler to solve. 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 2389BC4332F for ; Fri, 21 Oct 2022 08:36:24 +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=TWF68sSmoMq8qVRq+Vv/0oXvpBd7W265eRj/LU09jCA=; b=BOVxep3CaUsr0P RmFIFaYadPOt4jlxIPEWgoTfpirhGgtoyQR5eSfoeHrDUNIfOkbJauP6VrYlkpBatTUkM4otNV3OO dtN/J3wSlNwscX+Kyo7nsebbbWQbzxs2x7HAnOcglvWsLzHWS2XqOv4s20ZIiapklE5AW+JIx7Gdi HPw81NORqnII8wjFByXOzXM0oLydjkrJNGo0krziLJRMh0Ije6hzbzntQLM3xSF6jRXC1AZDThuew tVY/9ftr/dNH8ncBQ0wVhShpzmoxn0BUnr/z7XcFfXjeQQlxuXDNshKZi+dZXIuh3iOmRodIvC5Sx JDvit3LIgxi3sVjhEiBQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1olnVl-006PSk-VM; Fri, 21 Oct 2022 08:36:14 +0000 Received: from ams.source.kernel.org ([145.40.68.75]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1olnVi-006PQW-0z for linux-mtd@lists.infradead.org; Fri, 21 Oct 2022 08:36:11 +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 ams.source.kernel.org (Postfix) with ESMTPS id 95B30B82B63; Fri, 21 Oct 2022 08:36:08 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id C57E2C433D6; Fri, 21 Oct 2022 08:36:06 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1666341367; bh=VYkxOdyqZTRP94uFOMrKlhrYPkv6+oVeaJOCigiokeE=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=0LHArjuO/emmogeedg4sidpH81EIC1oFajIQk20rr9Km/Y0ewObOQB0i43jXid6V8 MEWVl4mxIE2auEWLdOFh5S0zN7a5cdswL8kZv1F5sHrcBCX+9z8wc+kpjX8Czr8S07 DVGuTf4yxBxOxcpimxvN26SCCFuV+ZffgRv7I1WQ= Date: Fri, 21 Oct 2022 10:36:04 +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 00/11] fix memory leak while kset_register() fails Message-ID: References: <20221021022102.2231464-1-yangyingliang@huawei.com> <0591e66f-731a-5f81-fc9d-3a6d80516c65@huawei.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <0591e66f-731a-5f81-fc9d-3a6d80516c65@huawei.com> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20221021_013610_394442_1CE91EC9 X-CRM114-Status: GOOD ( 32.04 ) 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: "linux-mtd" Errors-To: linux-mtd-bounces+linux-mtd=archiver.kernel.org@lists.infradead.org On Fri, Oct 21, 2022 at 04:24:23PM +0800, Yang Yingliang wrote: > = > On 2022/10/21 13:37, Greg KH wrote: > > On Fri, Oct 21, 2022 at 01:29:31AM -0400, Luben Tuikov wrote: > > > On 2022-10-20 22:20, Yang Yingliang wrote: > > > > The previous discussion link: > > > > https://lore.kernel.org/lkml/0db486eb-6927-927e-3629-958f8f211194@h= uawei.com/T/ > > > The very first discussion on this was here: > > > = > > > https://www.spinics.net/lists/dri-devel/msg368077.html > > > = > > > Please use this link, and not the that one up there you which quoted = above, > > > and whose commit description is taken verbatim from the this link. > > > = > > > > 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(). > > > As I explained in the link above, the reason there's > > > a memory leak is that one cannot call kset_register() without > > > the kset->kobj.name being set--kobj_add_internal() returns -EINVAL, > > > in this case, i.e. kset_register() fails with -EINVAL. > > > = > > > Thus, the most common usage is something like this: > > > = > > > kobj_set_name(&kset->kobj, format, ...); > > > kset->kobj.kset =3D parent_kset; > > > kset->kobj.ktype =3D ktype; > > > res =3D kset_register(kset); > > > = > > > So, what is being leaked, is the memory allocated in kobj_set_name(), > > > by the common idiom shown above. This needs to be mentioned in > > > the documentation, at least, in case, in the future this is absolved > > > in kset_register() redesign, etc. > > Based on this, can kset_register() just clean up from itself when an > > error happens? Ideally that would be the case, as the odds of a kset > > being embedded in a larger structure is probably slim, but we would have > > to search the tree to make sure. > I have search the whole tree, the kset used in bus_register() - patch #3, > kset_create_and_add() - patch #4 > __class_register() - patch #5,=A0 fw_cfg_build_symlink() - patch #6 and > amdgpu_discovery.c - patch #10 > is embedded in a larger structure. In these cases, we can not call > kset_put() in error path in kset_register() Yes you can as the kobject in the kset should NOT be controling the lifespan of those larger objects. If it is, please point out the call chain here as I don't think that should be possible. Note all of this is a mess because the kobject name stuff was added much later, after the driver model had been created and running for a while. We missed this error path when adding the dynamic kobject name logic, thank for looking into this. If you could test the patch posted with your error injection systems, that could make this all much simpler to solve. 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 aib29ajc252.phx1.oracleemaildelivery.com (aib29ajc252.phx1.oracleemaildelivery.com [192.29.103.252]) (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 D6250C43217 for ; Fri, 21 Oct 2022 08:36:22 +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=5uvEWFT78AvyHqyXsWgJ3brc45kdwimTSI1+pSGRviI=; b=1Yp3bvmlHtOAKMMJh7sYvMhRmPXfVqLit84CZlQOjggL4jV87djCtS7PMV4o8tEvZtegkIzZ4sjy ijOLFqM+zARYEjojnlSO3Tl/AwBWIvI+69+sExIn4KL7nCb0HIB4H9BX3zZ0zca7P9WZV89YfX25 8mUGK7IcKzOyUAPa2sh5v4rHw5k3nuu+gAqs6zGM1ku933CQk2CpOwWYFlKR5OxWyqFh9CtrO+As aRpWH6rKTD9mddE5x9f3k5fjTpEjUZFMHDT9dA7qPvLBXeioTlT3oNTf0AKp0gMypISrjUvL+TfW beBP5Wig3dhWY0Se3OZ1X3Vd75zAflyH+FTclw== 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=5uvEWFT78AvyHqyXsWgJ3brc45kdwimTSI1+pSGRviI=; b=fIKmClSypNOZifRRktkzMQM4WolkQDBYFCNxn2VlPIS5SdKxu+xFQRyFnI3BlSSDPBHupq0THBjl k+HbUqyt1m3CKSIEh7gZvshDEV1KpX6p9xjLx8tkabFbvhhkXzvtKgy3MEWTGzxiwZ3DiwmJ8KNT MeEqZTkpAqV0p38YiZEeBgLYsD7G8HUYNoU1f+laKXxH0/yrIaZZBvWPUbYIOU6+Nox26Sh3KrYa QjLLL6LsxH6Px2q4UqpwCjtRDKybTDHG/iTIzCVbNsPnuFBJke9kRCsTCIY3aW97DVMO6NapgM+t nmlpcQ0sQ+ReanAW2Q6jOoNBuhVnB6tuHuNxCQ== Received: by omta-ad3-fd1-301-us-phoenix-1.omtaad3.vcndpphx.oraclevcn.com (Oracle Communications Messaging Server 8.1.0.1.20220914 64bit (built Sep 14 2022)) with ESMTPS id <0RK300C5EH8MELB0@omta-ad3-fd1-301-us-phoenix-1.omtaad3.vcndpphx.oraclevcn.com> for ocfs2-devel@archiver.kernel.org; Fri, 21 Oct 2022 08:36:22 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1666341367; bh=VYkxOdyqZTRP94uFOMrKlhrYPkv6+oVeaJOCigiokeE=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=0LHArjuO/emmogeedg4sidpH81EIC1oFajIQk20rr9Km/Y0ewObOQB0i43jXid6V8 MEWVl4mxIE2auEWLdOFh5S0zN7a5cdswL8kZv1F5sHrcBCX+9z8wc+kpjX8Czr8S07 DVGuTf4yxBxOxcpimxvN26SCCFuV+ZffgRv7I1WQ= Date: Fri, 21 Oct 2022 10:36:04 +0200 To: Yang Yingliang Message-id: References: <20221021022102.2231464-1-yangyingliang@huawei.com> <0591e66f-731a-5f81-fc9d-3a6d80516c65@huawei.com> MIME-version: 1.0 Content-disposition: inline In-reply-to: <0591e66f-731a-5f81-fc9d-3a6d80516c65@huawei.com> X-Source-IP: 145.40.68.75 X-Proofpoint-Virus-Version: vendor=nai engine=6500 definitions=10506 signatures=596816 X-Proofpoint-Spam-Details: rule=tap_notspam policy=tap score=0 mlxscore=0 impostorscore=0 priorityscore=422 adultscore=0 clxscore=175 mlxlogscore=871 lowpriorityscore=0 spamscore=0 bulkscore=0 phishscore=0 suspectscore=0 malwarescore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2209130000 definitions=main-2210210049 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 00/11] fix memory leak while kset_register() fails 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="iso-8859-1" Content-transfer-encoding: quoted-printable Errors-to: ocfs2-devel-bounces@oss.oracle.com X-ServerName: ams.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: vPoXpZZkJFtQG84r5TOYptq7V7FNxcTn X-Proofpoint-GUID: vPoXpZZkJFtQG84r5TOYptq7V7FNxcTn Reporting-Meta: AAGRY6MvRQAgndvPA2e1b5LD35ynVyl3CfZlE7JDCoDxu9hBBt8E8X5ZDTjCjNcd ugR/S2MEMAVQe4Q2p1F+gBQOohJOuii1SRX5JVrYylLAamvW8om0OREhtVeCENc7 hUAcq+kih3CaYd6b9FMMBISFSgTCtmMDKA2pyUi1Mp3La8CENTM920EmxuVIvLpz oWbmf12BoKNO53NuzBYgirvccIf3TxiBaeyVaVSqg17vPr2etIp7E4+uAGStwZTx h61lBO9TMphnSE/p0noPVIyPGB8+bB8BSA34S1/9vGvC3QlFnO6DkDXgC3zceRKu UdszlNDeYYIPQQKpRjpHSuBxu8GcKh7TgUpObDN6bOd9kICjfWQmCMoPsOVxG9r+ KGTUE8hSaMbc3eZitb/PwFWC/lPc+KvNnyMEPTP5Puz0aGPovsuMrTxldAAQ1Klr wHkrP8UQnK5wvCevmt7kLE6uCyzIzk9pdcuBHhvv1clOjPrMEyokdtmgWrXAboIH 8IcwuHnUp4mvHX0G4zkKE8ld4v2OYNP6PSRajoFvjgw= On Fri, Oct 21, 2022 at 04:24:23PM +0800, Yang Yingliang wrote: > = > On 2022/10/21 13:37, Greg KH wrote: > > On Fri, Oct 21, 2022 at 01:29:31AM -0400, Luben Tuikov wrote: > > > On 2022-10-20 22:20, Yang Yingliang wrote: > > > > The previous discussion link: > > > > https://lore.kernel.org/lkml/0db486eb-6927-927e-3629-958f8f211194@h= uawei.com/T/ > > > The very first discussion on this was here: > > > = > > > https://www.spinics.net/lists/dri-devel/msg368077.html > > > = > > > Please use this link, and not the that one up there you which quoted = above, > > > and whose commit description is taken verbatim from the this link. > > > = > > > > 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(). > > > As I explained in the link above, the reason there's > > > a memory leak is that one cannot call kset_register() without > > > the kset->kobj.name being set--kobj_add_internal() returns -EINVAL, > > > in this case, i.e. kset_register() fails with -EINVAL. > > > = > > > Thus, the most common usage is something like this: > > > = > > > kobj_set_name(&kset->kobj, format, ...); > > > kset->kobj.kset =3D parent_kset; > > > kset->kobj.ktype =3D ktype; > > > res =3D kset_register(kset); > > > = > > > So, what is being leaked, is the memory allocated in kobj_set_name(), > > > by the common idiom shown above. This needs to be mentioned in > > > the documentation, at least, in case, in the future this is absolved > > > in kset_register() redesign, etc. > > Based on this, can kset_register() just clean up from itself when an > > error happens? Ideally that would be the case, as the odds of a kset > > being embedded in a larger structure is probably slim, but we would have > > to search the tree to make sure. > I have search the whole tree, the kset used in bus_register() - patch #3, > kset_create_and_add() - patch #4 > __class_register() - patch #5,=A0 fw_cfg_build_symlink() - patch #6 and > amdgpu_discovery.c - patch #10 > is embedded in a larger structure. In these cases, we can not call > kset_put() in error path in kset_register() Yes you can as the kobject in the kset should NOT be controling the lifespan of those larger objects. If it is, please point out the call chain here as I don't think that should be possible. Note all of this is a mess because the kobject name stuff was added much later, after the driver model had been created and running for a while. We missed this error path when adding the dynamic kobject name logic, thank for looking into this. If you could test the patch posted with your error injection systems, that could make this all much simpler to solve. 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 9FDCBC433FE for ; Fri, 21 Oct 2022 08:36:35 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230008AbiJUIgd (ORCPT ); Fri, 21 Oct 2022 04:36:33 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46186 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230022AbiJUIg1 (ORCPT ); Fri, 21 Oct 2022 04:36:27 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 32CF83B9A1 for ; Fri, 21 Oct 2022 01:36:20 -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 dfw.source.kernel.org (Postfix) with ESMTPS id E113761DFB for ; Fri, 21 Oct 2022 08:36:07 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id C57E2C433D6; Fri, 21 Oct 2022 08:36:06 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1666341367; bh=VYkxOdyqZTRP94uFOMrKlhrYPkv6+oVeaJOCigiokeE=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=0LHArjuO/emmogeedg4sidpH81EIC1oFajIQk20rr9Km/Y0ewObOQB0i43jXid6V8 MEWVl4mxIE2auEWLdOFh5S0zN7a5cdswL8kZv1F5sHrcBCX+9z8wc+kpjX8Czr8S07 DVGuTf4yxBxOxcpimxvN26SCCFuV+ZffgRv7I1WQ= Date: Fri, 21 Oct 2022 10:36:04 +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 00/11] fix memory leak while kset_register() fails Message-ID: References: <20221021022102.2231464-1-yangyingliang@huawei.com> <0591e66f-731a-5f81-fc9d-3a6d80516c65@huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <0591e66f-731a-5f81-fc9d-3a6d80516c65@huawei.com> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Oct 21, 2022 at 04:24:23PM +0800, Yang Yingliang wrote: > > On 2022/10/21 13:37, Greg KH wrote: > > On Fri, Oct 21, 2022 at 01:29:31AM -0400, Luben Tuikov wrote: > > > On 2022-10-20 22:20, Yang Yingliang wrote: > > > > The previous discussion link: > > > > https://lore.kernel.org/lkml/0db486eb-6927-927e-3629-958f8f211194@huawei.com/T/ > > > The very first discussion on this was here: > > > > > > https://www.spinics.net/lists/dri-devel/msg368077.html > > > > > > Please use this link, and not the that one up there you which quoted above, > > > and whose commit description is taken verbatim from the this link. > > > > > > > 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(). > > > As I explained in the link above, the reason there's > > > a memory leak is that one cannot call kset_register() without > > > the kset->kobj.name being set--kobj_add_internal() returns -EINVAL, > > > in this case, i.e. kset_register() fails with -EINVAL. > > > > > > Thus, the most common usage is something like this: > > > > > > kobj_set_name(&kset->kobj, format, ...); > > > kset->kobj.kset = parent_kset; > > > kset->kobj.ktype = ktype; > > > res = kset_register(kset); > > > > > > So, what is being leaked, is the memory allocated in kobj_set_name(), > > > by the common idiom shown above. This needs to be mentioned in > > > the documentation, at least, in case, in the future this is absolved > > > in kset_register() redesign, etc. > > Based on this, can kset_register() just clean up from itself when an > > error happens? Ideally that would be the case, as the odds of a kset > > being embedded in a larger structure is probably slim, but we would have > > to search the tree to make sure. > I have search the whole tree, the kset used in bus_register() - patch #3, > kset_create_and_add() - patch #4 > __class_register() - patch #5,  fw_cfg_build_symlink() - patch #6 and > amdgpu_discovery.c - patch #10 > is embedded in a larger structure. In these cases, we can not call > kset_put() in error path in kset_register() Yes you can as the kobject in the kset should NOT be controling the lifespan of those larger objects. If it is, please point out the call chain here as I don't think that should be possible. Note all of this is a mess because the kobject name stuff was added much later, after the driver model had been created and running for a while. We missed this error path when adding the dynamic kobject name logic, thank for looking into this. If you could test the patch posted with your error injection systems, that could make this all much simpler to solve. thanks, greg k-h