[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20130926144208.GC12301@hmsreliant.think-freely.org>
Date: Thu, 26 Sep 2013 10:42:08 -0400
From: Neil Horman <nhorman@...driver.com>
To: Veaceslav Falico <vfalico@...hat.com>
Cc: linux-pci@...r.kernel.org, Bjorn Helgaas <bhelgaas@...gle.com>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2] msi: free msi_desc entry only after we've released
the kobject
On Thu, Sep 26, 2013 at 11:59:51AM +0200, 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@...gle.com>
> CC: Neil Horman <nhorman@...driver.com>
> CC: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
> CC: linux-pci@...r.kernel.org
> CC: linux-kernel@...r.kernel.org
> Signed-off-by: Veaceslav Falico <vfalico@...hat.com>
> ---
>
Acked-by: Neil Horman <nhorman@...driver.com>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists