ebiederm@xxxxxxxxxxxx (Eric W. Biederman) writes: > Christoph Lameter <cl@xxxxxxxxx> writes: > >> Another version that drops the slub lock for both invocations of sysfs >> functions from kmem_cache_create. The invocation from slab_sysfs_init >> is not a problem since user space is not active at that point. >> >> >> Subject: slub: Do not take the slub lock while calling into sysfs >> >> This patch avoids holding the slub_lock during kmem_cache_create() >> when calling sysfs. It is possible because kmem_cache_create() >> allocates the kmem_cache object and therefore is the only one context >> that can access the newly created object. It is therefore possible >> to drop the slub_lock early. We defer the adding of the new kmem_cache >> to the end of processing because the new kmem_cache structure would >> be reachable otherwise via scans over slabs. This allows sysfs_slab_add() >> to run without holding any locks. >> >> The case is different if we are creating an alias instead of a new >> kmem_cache structure. In that case we can also drop the slub lock >> early because we have taken a refcount on the kmem_cache structure. >> It therefore cannot vanish from under us. >> But if the sysfs_slab_alias() call fails we can no longer simply >> decrement the refcount since the other references may have gone >> away in the meantime. Call kmem_cache_destroy() to cause the >> refcount to be decremented and the kmem_cache structure to be >> freed if all references are gone. >> >> Signed-off-by: Christoph Lameter <cl@xxxxxxxxx> > > I am dense. Is the deadlock here that you are fixing slub calling sysfs > with the slub_lock held but sysfs then calling kmem_cache_zalloc? > > I don't see what sysfs is doing in the creation path that would cause > a deadlock except for using slab. Oh. I see. The problem is calling kobject_uevent (which happens to live in slabs sysfs_slab_add) with a lock held. And kobject_uevent makes a blocking call to userspace. No locks held seems to be a good policy on that one. Eric -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
