Messages in this thread | | | Date | Wed, 3 Jun 2020 15:36:50 -0300 | From | Jason Gunthorpe <> | Subject | Re: kobject_init_and_add is easy to misuse |
| |
On Wed, Jun 03, 2020 at 11:04:35AM -0700, James Bottomley wrote: > On Tue, 2020-06-02 at 21:22 -0300, Jason Gunthorpe wrote: > > On Tue, Jun 02, 2020 at 02:51:10PM -0700, James Bottomley wrote: > > > > > My first thought was "what? I got suckered into creating a patch", > > > thanks ;-) But now I look, all the error paths do unwind back to > > > the initial state, so kfree() on error looks to be completely > > > correct. > > > > It doesn't fully unwind if the kobject is put into a kset, then > > another thread can get the kref during kset_find_obj() and kfree() > > won't wait for the kref to go to 0. It must use put. > > That does seem a bit contrived: the only failure kobject_add_internal() > can get after kobj_kset_join() is from directory creation. If > directory creation fails, no name appears in sysfs and no event for the > name is sent, how did another thread get the name to pass in to > kset_find_obj()?
The other thread just guesses in a hostile way?
Eg it looks like the iommu stuff just feeds in user data to kobj_kset_join().
Jason
| |