From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753604AbbFHUz5 (ORCPT ); Mon, 8 Jun 2015 16:55:57 -0400 Received: from mail.linuxfoundation.org ([140.211.169.12]:57858 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753558AbbFHUzh (ORCPT ); Mon, 8 Jun 2015 16:55:37 -0400 Date: Mon, 8 Jun 2015 13:55:36 -0700 From: Greg KH To: Chen Lin Z Cc: linux-kernel@vger.kernel.org, bo.he@intel.com, yanmin_zhang@linux.intel.com Subject: Re: [PATCH] class: Free the kobject.name if kset_register fails Message-ID: <20150608205536.GA11211@kroah.com> References: <1433749777-9647-1-git-send-email-lin.z.chen@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1433749777-9647-1-git-send-email-lin.z.chen@intel.com> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Jun 08, 2015 at 03:49:37PM +0800, Chen Lin Z wrote: > Fix a memory leak by freeing the memory allocated in kobject_set_name > for the kobjet name. > > unreferenced object 0xe2167700 (size 64): > comm "swapper/0", pid 1, jiffies 4294938161 (age 90.540s) > hex dump (first 32 bytes): > 6d 61 67 6e 65 74 69 63 00 11 c2 c0 1f e9 23 c1 magnetic......#. > 18 00 00 00 04 66 9b e4 e0 66 9b e4 94 76 16 e2 .....f...f...v.. > backtrace: > [] kmemleak_alloc+0x3c/0xa0 > [] __kmalloc_track_caller+0x115/0x1d0 > [] kvasprintf+0x33/0x60 > [] kobject_set_name_vargs+0x22/0x60 > [] kobject_set_name+0x11/0x20 > [] __class_register+0x8e/0x1e0 > [] __class_create+0x4b/0x70 > [] mmc3524x_init+0x18/0x97 > [] do_one_initcall+0xbc/0x190 > [] kernel_init_freeable+0xea/0x18c > [] kernel_init+0x10/0xe0 > [] ret_from_kernel_thread+0x1b/0x28 > [] 0xffffffff > > Signed-off-by: Chen Lin Z > --- > drivers/base/class.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/base/class.c b/drivers/base/class.c > index 6e81088..f6e7f53 100644 > --- a/drivers/base/class.c > +++ b/drivers/base/class.c > @@ -200,6 +200,7 @@ int __class_register(struct class *cls, struct lock_class_key *key) > > error = kset_register(&cp->subsys); > if (error) { > + kfree(cp->subsys.kobj.name); How did you ever trigger this error case? I don't like mucking about in the root of the kobject name structure, as who knows what is really happening there. Isn't there some other "better" way to resolve this? thanks, greg k-h