[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190428011957.GA18843@eros.localdomain>
Date: Sun, 28 Apr 2019 11:19:57 +1000
From: "Tobin C. Harding" <me@...in.cc>
To: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc: "Rafael J. Wysocki" <rafael@...nel.org>, cl@...ux.com,
tycho@...ho.ws, willy@...radead.org, linux-kernel@...r.kernel.org
Subject: Re: memleak around kobject_init_and_add()
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(). 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())?
Cheers,
Tobin.
Powered by blists - more mailing lists