Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp2799565yba; Sun, 28 Apr 2019 09:17:22 -0700 (PDT) X-Google-Smtp-Source: APXvYqzAhSWkPary/ECd3+hkL6QN1GPTyqp4oeEhOCrEHBGYoPWjPPp+ADxggzDOV+CpFIabYwDJ X-Received: by 2002:a17:902:bb97:: with SMTP id m23mr56512pls.155.1556468242138; Sun, 28 Apr 2019 09:17:22 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1556468242; cv=none; d=google.com; s=arc-20160816; b=axwPlC6Qp/lDWA7rkcObZSR82rcwkcvitWZamU0RzjWShlFJqw9PKu0P9yxA+7tv6j Cxd6vHMiFISNhftireRTu11W9JNJkIBTTIY05U8Letpo4sIbDfh6EmqR2B9A/vrd2OC2 GXjwBEKHivpg4zJzEBEHedGq8K78LTuDUb+/aRSjkAIbIGJV2VpmT0KlvRwjIzzz2z/n +uQQC7/6nyAXBMFEo//hYlZ6bjqJh6+37Vzxvx/9nitMkHIgHK3GsuUVs7oELN07Sv+M EXba1dEOlKPghDmMbTjwpY2UpEyYsSLUx8IZiH6BkVG+In4/rc9OjzVWIUMRCeNqdkrs Gr+g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature; bh=Z1E2eWzTcpCrl9OCUct8kYFwXcFeihKEzJWrFrBZL44=; b=QZ6IQRKd5Ia8UMvechCt4yE6Wa48skWSymS31aNgFlcfKL5RDu8fYc1f1qpOitAAo+ WHdKN8YQLLy5hiEt+3HOevM6JoUChYMMoHnJczjP/JKJjoaTgqZCGqFILepsJFVrXHZh 0MOmLixUUZdFZN4Nyh6B2DdVbpVQUu6CAUKsIA3+bXmb1dCXx9SBlxRvMFXrm+eL/366 tGFSAYZYJ39JpIHmnR8E9vci5qbjAuMoDNVy5UotnwjoNHWNR15iRnpbkjixmQYzABnL JIb37gINspdafgpaa3zSGchSOk1JedFh/EJ8jq80XBGERKrOiiJo8Ze1ChOkudMke0WH IULA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=SIcmVvMo; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id m3si31616178plb.245.2019.04.28.09.17.06; Sun, 28 Apr 2019 09:17:22 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=SIcmVvMo; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726901AbfD1QPB (ORCPT + 99 others); Sun, 28 Apr 2019 12:15:01 -0400 Received: from mail.kernel.org ([198.145.29.99]:57270 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726818AbfD1QPB (ORCPT ); Sun, 28 Apr 2019 12:15:01 -0400 Received: from localhost (83-86-89-107.cable.dynamic.v4.ziggo.nl [83.86.89.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id D158F206BB; Sun, 28 Apr 2019 16:14:59 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1556468100; bh=Z2d74mf++K8b222mNrf6+2RpM7/IWNqzhtE4h+cyd64=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=SIcmVvMoRy6z6VL/KInWG81bXFrspiyFROo9q+J3+vWSVhD4rXLL8Fam0CshNFpFO sKGsiIBBeJy0UfHjST9urxQuQ3Kr+EsrbB8Co6vmcFf8zgvRbT1x8SNzIbx/5uctOu W0UdwmlSZDcgOOCM43R9G5yRw8IydKQNkipgt2/w= Date: Sun, 28 Apr 2019 18:14:58 +0200 From: Greg Kroah-Hartman To: "Tobin C. Harding" Cc: "Rafael J. Wysocki" , cl@linux.com, tycho@tycho.ws, willy@infradead.org, linux-kernel@vger.kernel.org Subject: Re: memleak around kobject_init_and_add() Message-ID: <20190428161458.GB13309@kroah.com> References: <20190427081330.GA26788@eros.localdomain> <20190427192809.GA8454@kroah.com> <20190428011957.GA18843@eros.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190428011957.GA18843@eros.localdomain> User-Agent: Mutt/1.11.4 (2019-03-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sun, Apr 28, 2019 at 11:19:57AM +1000, Tobin C. Harding wrote: > On Sat, Apr 27, 2019 at 09:28:09PM +0200, Greg Kroah-Hartman wrote: > > On Sat, Apr 27, 2019 at 06:13:30PM +1000, Tobin C. Harding wrote: > > > (Note at bottom on reasons for 'To' list 'Cc' list) > > > > > > Hi, > > > > > > kobject_init_and_add() seems to be routinely misused. A failed call to this > > > function requires a call to kobject_put() otherwise we leak memory. > > > > > > Examples memleaks can be seen in: > > > > > > mm/slub.c > > > fs/btrfs/sysfs.c > > > fs/xfs/xfs_sysfs.h: xfs_sysfs_init() > > > > > > Question: Do we fix the misuse or fix the API? > > > > Fix the misuse. > > Following on from this. It seems we often also forget to call > kobject_uevent() after calls to kobject_init_and_add(). Are you sure? Usually if you don't call it right away, it happens much later when you have everything "ready to go" to tell userspace that it then can access that kobject successfully. Any specific places you feel is not correct? > Before I make a goose of myself patching the whole tree is there ever > any reason why we would _not_ want to call kobject_uevent() after > successfully calling kobject_add() (or kobject_init_and_add())? You should always do so, but again, sometimes it can be much "later" after everything is properly set up. Ok, at quick glance I see some places that do not properly call this. But, those places should not even be using a "raw" kobject in the first place, they should be using 'struct device'. If code using a kobject, that should be very "rare", and not normal behavior in the first place. thanks, greg k-h