Re: memleak around kobject_init_and_add()

[Greg Kroah-Hartman]

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