On Mon, Nov 25, 2013 at 04:12:48PM -0700, Bjorn Helgaas wrote: > On Tue, Oct 29, 2013 at 11:30:30AM +0100, Veaceslav Falico wrote: > > Currently, we first do kobject_put(&entry->kobj) and the kfree(entry), > > however kobject_put() doesn't guarantee us that it was the last reference > > and that the kobj isn't used currently by someone else, so after we > > kfree(entry) with the struct kobject - other users will begin using the > > freed memory, instead of the actual kobject. > > > > Fix this by using the kobject->release callback, which is called last when > > the kobject is indeed not used and is cleaned up - it's msi_kobj_release(), > > which can do the kfree(entry) safely (kobject_put/cleanup doesn't use the > > kobj itself after ->release() was called, so we're safe). > > > > In case we've failed to create the sysfs directories - just kfree() > > it - cause we don't have the kobjects attached. > > > > Also, remove the same functionality from populate_msi_sysfs(), cause on > > failure we anyway call free_msi_irqs(), which will take care of all the > > kobjects properly. > > > > And add the forgotten pci_dev_put(pdev) in case of failure to register the > > kobject in populate_msi_sysfs(). > > > > CC: Bjorn Helgaas <bhelgaas@xxxxxxxxxx> > > CC: Neil Horman <nhorman@xxxxxxxxxxxxx> > > CC: Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx> > > CC: linux-pci@xxxxxxxxxxxxxxx > > CC: linux-kernel@xxxxxxxxxxxxxxx > > Signed-off-by: Veaceslav Falico <vfalico@xxxxxxxxxx> > > I'm still hoping that Greg (or somebody else; Greg already posted the bulk > of the work) will finish up the conversion to attributes, and that Neil > will confirm that works with no changes to irqbalance. So I'm going to > drop these patches for now. Poke me if we need to revive them. Ah, sorry about that. I'll redo my series, dropping the existing format and using the attribute-only code. Give me a day or so, thanks for the reminder. greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
