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.
