[<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
 
