Re: SLUB: kmem_cache_destroy doesn't - version 2.

[Christoph Lameter <clameter@sgi.com>]

On Fri, 20 Apr 2007, Neil Brown wrote:

> Not sure how best to fix this one.... kmem_cache_destroy currently
> doesn't know which alias is being destroyed.

The aliases are there for decorative purposes when running without
debugging. If one switches on debugging then it matters but then the
symlinks are not created since there will be no aliases.

I guess we can ignore the problem?


Index: linux-2.6.21-rc6/mm/slub.c
===================================================================
--- linux-2.6.21-rc6.orig/mm/slub.c	2007-04-19 22:13:28.000000000 -0700
+++ linux-2.6.21-rc6/mm/slub.c	2007-04-19 22:15:31.000000000 -0700
@@ -3351,9 +3351,19 @@ static int sysfs_slab_alias(struct kmem_
 {
 	struct saved_alias *al;
 
-	if (slab_state == SYSFS)
-		return sysfs_create_link(&slab_subsys.kset.kobj,
+	if (slab_state == SYSFS) {
+		int rc;
+
+		/*
+		 * Aliases are there mainly for decorative purposes
+		 * and we have no way of removing them properly.
+		 * Creating a link may fail due to the symlink remaining.
+		 * f.e. module unloading and loading.
+		 */
+		rc = sysfs_create_link(&slab_subsys.kset.kobj,
 						&s->kobj, name);
+		return 0;
+	}
 
 	al = kmalloc(sizeof(struct saved_alias), GFP_KERNEL);
 	if (!al)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/