slub: avoid leaking caches or refcounts on sysfs error
authorDavid Rientjes <rientjes@google.com>
Thu, 18 Dec 2008 06:09:46 +0000 (22:09 -0800)
committerPekka Enberg <penberg@cs.helsinki.fi>
Mon, 29 Dec 2008 09:40:58 +0000 (11:40 +0200)
commit7b8f3b66d9d7e5f021ae535620b9b52833f4876e
tree0495da27c549f9abd8bcb75c158edf20e35ca711
parentdfcd3610289132a762b7dc0eaf33998262cd9e20
slub: avoid leaking caches or refcounts on sysfs error

If a slab cache is mergeable and the sysfs alias cannot be added, the
target cache shall have its refcount decremented.  kmem_cache_create()
will return NULL, so if kmem_cache_destroy() is ever called on the target
cache, it will never be freed if the refcount has been leaked.

Likewise, if a slab cache is not mergeable and the sysfs link cannot be
added, the new cache shall be removed from the slab_caches list.
kmem_cache_create() will return NULL, so it will be impossible to call
kmem_cache_destroy() on it.

Both of these operations require slub_lock since refcount of all slab
caches and slab_caches are protected by the lock.

In the mergeable case, it would be better to restore objsize and offset
back to their original values, but this could race with another merge
since slub_lock was dropped.

Cc: Christoph Lameter <cl@linux-foundation.org>
Signed-off-by: David Rientjes <rientjes@google.com>
Signed-off-by: Pekka Enberg <penberg@cs.helsinki.fi>
mm/slub.c