[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <20131008201915.19377.34185.stgit@bhelgaas-glaptop.roam.corp.google.com>
Date: Tue, 08 Oct 2013 14:20:07 -0600
From: Bjorn Helgaas <bhelgaas@...gle.com>
To: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc: Veaceslav Falico <vfalico@...hat.com>,
Russell King <linux@....linux.org.uk>,
Neil Horman <nhorman@...driver.com>, linux-pci@...r.kernel.org,
linux-kernel@...r.kernel.org, Zdenek Kabelac <zkabelac@...hat.com>
Subject: [PATCH 0/2] Remove ksets from sysfs eagerly
With CONFIG_DEBUG_KOBJECT_RELEASE=y, kobject release is delayed even after
the last reference to the object is dropped.
With this turned on, Veaceslav and Zdenek noticed that when we enable,
disable, and re-enable MSIs, we often see errors like "sysfs: cannot create
duplicate filename '/devices/pci0000:00/.../msi_irqs'". This happens
when we unload and reload drivers that use MSI.
The reason is that the MSI disable path uses kset_unregister(dev->msi_kset),
which doesn't remove the kset from sysfs until the the kobject release
function is called. With CONFIG_DEBUG_KOBJECT_RELEASE, the release is
obviously delayed, but even without it, the release will be delayed if
somebody has the kset sysfs file open when kset_unregister() is called.
We could work around this by explicitly calling
"kobject_del(&dev->msi_kset->kobj)", but that seems clunky and other
kset_unregister() users are likely to have similar problems.
The idea of this patch is to make kset_unregister() unlink the kset from
sysfs immediately, before dropping the kset reference.
---
Bjorn Helgaas (2):
kobject: remove kset from sysfs immediately in kset_unregister()
kobject: fix kset sample error path
Documentation/kobject.txt | 3 ++-
lib/kobject.c | 1 +
samples/kobject/kset-example.c | 1 +
3 files changed, 4 insertions(+), 1 deletion(-)
--
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