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
