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;
User-Agent: Cyrus-JMAP/3.1.6-444-g755619f-fmstable-20190423v1
Mime-Version: 1.0
Message-Id: <c4caa4e2-fca4-455f-8f2d-308281762acd@www.fastmail.com>
In-Reply-To: <20190428161458.GB13309@kroah.com>
References: <20190427081330.GA26788@eros.localdomain>
 <20190427192809.GA8454@kroah.com> <20190428011957.GA18843@eros.localdomain>
 <20190428161458.GB13309@kroah.com>
Date:   Sun, 28 Apr 2019 18:46:38 -0400
From:   "Tobin C. Harding" <me@tobin.cc>
To:     "Greg Kroah-Hartman" <gregkh@linuxfoundation.org>
Cc:     "Rafael J. Wysocki" <rafael@kernel.org>,
        "Christopher Lameter" <cl@linux.com>,
        "Tycho Andersen" <tycho@tycho.ws>, willy@infradead.org,
        linux-kernel@vger.kernel.org
Subject: Re: memleak around kobject_init_and_add()
Content-Type: text/plain
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Mon, Apr 29, 2019, at 02:15, Greg Kroah-Hartman wrote:
> 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.

Cool, thanks.