All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH v2] slab+slob: dup name string
@ 2012-05-22  9:51 ` Glauber Costa
  0 siblings, 0 replies; 21+ messages in thread
From: Glauber Costa @ 2012-05-22  9:51 UTC (permalink / raw)
  To: linux-kernel
  Cc: cgroups, linux-mm, Glauber Costa, Christoph Lameter,
	Pekka Enberg, David Rientjes

The slub allocator creates a copy of the name string, and
frees it later. I would like all caches to behave the same,
whether it is the slab+slob starting to create a copy of it itself,
or the slub ceasing to.

This patch creates copies of the name string for slob and slab,
adopting slub behavior for them all.

For the slab, we can't really do it before the kmalloc caches are
up. So we manually do it before the end of EARLY phase, and conditionally
do it for the caches created afterwards.

[ v2: Also dup string for early caches, requested by David Rientjes ]

Signed-off-by: Glauber Costa <glommer@parallels.com>
CC: Christoph Lameter <cl@linux.com>
CC: Pekka Enberg <penberg@cs.helsinki.fi>
CC: David Rientjes <rientjes@google.com>
---
 mm/slab.c |   37 +++++++++++++++++++++++++++++++++++--
 mm/slob.c |   12 ++++++++++--
 2 files changed, 45 insertions(+), 4 deletions(-)

diff --git a/mm/slab.c b/mm/slab.c
index e901a36..fe05f8bf 100644
--- a/mm/slab.c
+++ b/mm/slab.c
@@ -1676,6 +1676,33 @@ void __init kmem_cache_init(void)
 		}
 	}
 
+	/*
+	 * create a copy of all the name strings for early caches. This is
+	 * so deleting those caches will work in a consistent way. We don't
+	 * expect allocation failures this early in the process, just make sure
+	 * they didn't happen.
+	 */
+	sizes = malloc_sizes;
+
+	while (sizes->cs_size != ULONG_MAX) {
+		struct kmem_cache *cachep;
+
+		cachep = sizes->cs_cachep;
+		if (cachep) {
+			cachep->name = kstrdup(cachep->name, GFP_NOWAIT);
+			BUG_ON(!cachep->name);
+		}
+
+		cachep = sizes->cs_dmacachep;
+		if (cachep) {
+			cachep->name = kstrdup(cachep->name, GFP_NOWAIT);
+			BUG_ON(!cachep->name);
+		}
+		sizes++;
+	}
+
+	cache_cache.name = kstrdup(cache_cache.name, GFP_NOWAIT);
+	BUG_ON(!cache_cache.name);
 	g_cpucache_up = EARLY;
 }
 
@@ -2118,6 +2145,7 @@ static void __kmem_cache_destroy(struct kmem_cache *cachep)
 			kfree(l3);
 		}
 	}
+	kfree(cachep->name);
 	kmem_cache_free(&cache_cache, cachep);
 }
 
@@ -2526,9 +2554,14 @@ kmem_cache_create (const char *name, size_t size, size_t align,
 		BUG_ON(ZERO_OR_NULL_PTR(cachep->slabp_cache));
 	}
 	cachep->ctor = ctor;
-	cachep->name = name;
 
-	if (setup_cpu_cache(cachep, gfp)) {
+	/* Can't do strdup while kmalloc is not up */
+	if (slab_is_available())
+		cachep->name = kstrdup(name, GFP_KERNEL);
+	else
+		cachep->name = name;
+
+	if (!cachep->name || setup_cpu_cache(cachep, gfp)) {
 		__kmem_cache_destroy(cachep);
 		cachep = NULL;
 		goto oops;
diff --git a/mm/slob.c b/mm/slob.c
index 8105be4..8f10d36 100644
--- a/mm/slob.c
+++ b/mm/slob.c
@@ -575,7 +575,12 @@ struct kmem_cache *kmem_cache_create(const char *name, size_t size,
 		GFP_KERNEL, ARCH_KMALLOC_MINALIGN, -1);
 
 	if (c) {
-		c->name = name;
+		c->name = kstrdup(name, GFP_KERNEL);
+		if (!c->name) {
+			slob_free(c, sizeof(struct kmem_cache));
+			c = NULL;
+			goto out;
+		}
 		c->size = size;
 		if (flags & SLAB_DESTROY_BY_RCU) {
 			/* leave room for rcu footer at the end of object */
@@ -589,7 +594,9 @@ struct kmem_cache *kmem_cache_create(const char *name, size_t size,
 			c->align = ARCH_SLAB_MINALIGN;
 		if (c->align < align)
 			c->align = align;
-	} else if (flags & SLAB_PANIC)
+	}
+out:
+	if (!c && (flags & SLAB_PANIC))
 		panic("Cannot create slab cache %s\n", name);
 
 	kmemleak_alloc(c, sizeof(struct kmem_cache), 1, GFP_KERNEL);
@@ -602,6 +609,7 @@ void kmem_cache_destroy(struct kmem_cache *c)
 	kmemleak_free(c);
 	if (c->flags & SLAB_DESTROY_BY_RCU)
 		rcu_barrier();
+	kfree(c->name);
 	slob_free(c, sizeof(struct kmem_cache));
 }
 EXPORT_SYMBOL(kmem_cache_destroy);
-- 
1.7.7.6


^ permalink raw reply related	[flat|nested] 21+ messages in thread

* [PATCH v2] slab+slob: dup name string
@ 2012-05-22  9:51 ` Glauber Costa
  0 siblings, 0 replies; 21+ messages in thread
From: Glauber Costa @ 2012-05-22  9:51 UTC (permalink / raw)
  To: linux-kernel
  Cc: cgroups, linux-mm, Glauber Costa, Christoph Lameter,
	Pekka Enberg, David Rientjes

The slub allocator creates a copy of the name string, and
frees it later. I would like all caches to behave the same,
whether it is the slab+slob starting to create a copy of it itself,
or the slub ceasing to.

This patch creates copies of the name string for slob and slab,
adopting slub behavior for them all.

For the slab, we can't really do it before the kmalloc caches are
up. So we manually do it before the end of EARLY phase, and conditionally
do it for the caches created afterwards.

[ v2: Also dup string for early caches, requested by David Rientjes ]

Signed-off-by: Glauber Costa <glommer@parallels.com>
CC: Christoph Lameter <cl@linux.com>
CC: Pekka Enberg <penberg@cs.helsinki.fi>
CC: David Rientjes <rientjes@google.com>
---
 mm/slab.c |   37 +++++++++++++++++++++++++++++++++++--
 mm/slob.c |   12 ++++++++++--
 2 files changed, 45 insertions(+), 4 deletions(-)

diff --git a/mm/slab.c b/mm/slab.c
index e901a36..fe05f8bf 100644
--- a/mm/slab.c
+++ b/mm/slab.c
@@ -1676,6 +1676,33 @@ void __init kmem_cache_init(void)
 		}
 	}
 
+	/*
+	 * create a copy of all the name strings for early caches. This is
+	 * so deleting those caches will work in a consistent way. We don't
+	 * expect allocation failures this early in the process, just make sure
+	 * they didn't happen.
+	 */
+	sizes = malloc_sizes;
+
+	while (sizes->cs_size != ULONG_MAX) {
+		struct kmem_cache *cachep;
+
+		cachep = sizes->cs_cachep;
+		if (cachep) {
+			cachep->name = kstrdup(cachep->name, GFP_NOWAIT);
+			BUG_ON(!cachep->name);
+		}
+
+		cachep = sizes->cs_dmacachep;
+		if (cachep) {
+			cachep->name = kstrdup(cachep->name, GFP_NOWAIT);
+			BUG_ON(!cachep->name);
+		}
+		sizes++;
+	}
+
+	cache_cache.name = kstrdup(cache_cache.name, GFP_NOWAIT);
+	BUG_ON(!cache_cache.name);
 	g_cpucache_up = EARLY;
 }
 
@@ -2118,6 +2145,7 @@ static void __kmem_cache_destroy(struct kmem_cache *cachep)
 			kfree(l3);
 		}
 	}
+	kfree(cachep->name);
 	kmem_cache_free(&cache_cache, cachep);
 }
 
@@ -2526,9 +2554,14 @@ kmem_cache_create (const char *name, size_t size, size_t align,
 		BUG_ON(ZERO_OR_NULL_PTR(cachep->slabp_cache));
 	}
 	cachep->ctor = ctor;
-	cachep->name = name;
 
-	if (setup_cpu_cache(cachep, gfp)) {
+	/* Can't do strdup while kmalloc is not up */
+	if (slab_is_available())
+		cachep->name = kstrdup(name, GFP_KERNEL);
+	else
+		cachep->name = name;
+
+	if (!cachep->name || setup_cpu_cache(cachep, gfp)) {
 		__kmem_cache_destroy(cachep);
 		cachep = NULL;
 		goto oops;
diff --git a/mm/slob.c b/mm/slob.c
index 8105be4..8f10d36 100644
--- a/mm/slob.c
+++ b/mm/slob.c
@@ -575,7 +575,12 @@ struct kmem_cache *kmem_cache_create(const char *name, size_t size,
 		GFP_KERNEL, ARCH_KMALLOC_MINALIGN, -1);
 
 	if (c) {
-		c->name = name;
+		c->name = kstrdup(name, GFP_KERNEL);
+		if (!c->name) {
+			slob_free(c, sizeof(struct kmem_cache));
+			c = NULL;
+			goto out;
+		}
 		c->size = size;
 		if (flags & SLAB_DESTROY_BY_RCU) {
 			/* leave room for rcu footer at the end of object */
@@ -589,7 +594,9 @@ struct kmem_cache *kmem_cache_create(const char *name, size_t size,
 			c->align = ARCH_SLAB_MINALIGN;
 		if (c->align < align)
 			c->align = align;
-	} else if (flags & SLAB_PANIC)
+	}
+out:
+	if (!c && (flags & SLAB_PANIC))
 		panic("Cannot create slab cache %s\n", name);
 
 	kmemleak_alloc(c, sizeof(struct kmem_cache), 1, GFP_KERNEL);
@@ -602,6 +609,7 @@ void kmem_cache_destroy(struct kmem_cache *c)
 	kmemleak_free(c);
 	if (c->flags & SLAB_DESTROY_BY_RCU)
 		rcu_barrier();
+	kfree(c->name);
 	slob_free(c, sizeof(struct kmem_cache));
 }
 EXPORT_SYMBOL(kmem_cache_destroy);
-- 
1.7.7.6

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

^ permalink raw reply related	[flat|nested] 21+ messages in thread

* [PATCH v2] slab+slob: dup name string
@ 2012-05-22  9:51 ` Glauber Costa
  0 siblings, 0 replies; 21+ messages in thread
From: Glauber Costa @ 2012-05-22  9:51 UTC (permalink / raw)
  To: linux-kernel-u79uwXL29TY76Z2rM5mHXA
  Cc: cgroups-u79uwXL29TY76Z2rM5mHXA, linux-mm-Bw31MaZKKs3YtjvyW6yDsg,
	Glauber Costa, Christoph Lameter, Pekka Enberg, David Rientjes

The slub allocator creates a copy of the name string, and
frees it later. I would like all caches to behave the same,
whether it is the slab+slob starting to create a copy of it itself,
or the slub ceasing to.

This patch creates copies of the name string for slob and slab,
adopting slub behavior for them all.

For the slab, we can't really do it before the kmalloc caches are
up. So we manually do it before the end of EARLY phase, and conditionally
do it for the caches created afterwards.

[ v2: Also dup string for early caches, requested by David Rientjes ]

Signed-off-by: Glauber Costa <glommer-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>
CC: Christoph Lameter <cl-vYTEC60ixJUAvxtiuMwx3w@public.gmane.org>
CC: Pekka Enberg <penberg-bbCR+/B0CizivPeTLB3BmA@public.gmane.org>
CC: David Rientjes <rientjes-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
---
 mm/slab.c |   37 +++++++++++++++++++++++++++++++++++--
 mm/slob.c |   12 ++++++++++--
 2 files changed, 45 insertions(+), 4 deletions(-)

diff --git a/mm/slab.c b/mm/slab.c
index e901a36..fe05f8bf 100644
--- a/mm/slab.c
+++ b/mm/slab.c
@@ -1676,6 +1676,33 @@ void __init kmem_cache_init(void)
 		}
 	}
 
+	/*
+	 * create a copy of all the name strings for early caches. This is
+	 * so deleting those caches will work in a consistent way. We don't
+	 * expect allocation failures this early in the process, just make sure
+	 * they didn't happen.
+	 */
+	sizes = malloc_sizes;
+
+	while (sizes->cs_size != ULONG_MAX) {
+		struct kmem_cache *cachep;
+
+		cachep = sizes->cs_cachep;
+		if (cachep) {
+			cachep->name = kstrdup(cachep->name, GFP_NOWAIT);
+			BUG_ON(!cachep->name);
+		}
+
+		cachep = sizes->cs_dmacachep;
+		if (cachep) {
+			cachep->name = kstrdup(cachep->name, GFP_NOWAIT);
+			BUG_ON(!cachep->name);
+		}
+		sizes++;
+	}
+
+	cache_cache.name = kstrdup(cache_cache.name, GFP_NOWAIT);
+	BUG_ON(!cache_cache.name);
 	g_cpucache_up = EARLY;
 }
 
@@ -2118,6 +2145,7 @@ static void __kmem_cache_destroy(struct kmem_cache *cachep)
 			kfree(l3);
 		}
 	}
+	kfree(cachep->name);
 	kmem_cache_free(&cache_cache, cachep);
 }
 
@@ -2526,9 +2554,14 @@ kmem_cache_create (const char *name, size_t size, size_t align,
 		BUG_ON(ZERO_OR_NULL_PTR(cachep->slabp_cache));
 	}
 	cachep->ctor = ctor;
-	cachep->name = name;
 
-	if (setup_cpu_cache(cachep, gfp)) {
+	/* Can't do strdup while kmalloc is not up */
+	if (slab_is_available())
+		cachep->name = kstrdup(name, GFP_KERNEL);
+	else
+		cachep->name = name;
+
+	if (!cachep->name || setup_cpu_cache(cachep, gfp)) {
 		__kmem_cache_destroy(cachep);
 		cachep = NULL;
 		goto oops;
diff --git a/mm/slob.c b/mm/slob.c
index 8105be4..8f10d36 100644
--- a/mm/slob.c
+++ b/mm/slob.c
@@ -575,7 +575,12 @@ struct kmem_cache *kmem_cache_create(const char *name, size_t size,
 		GFP_KERNEL, ARCH_KMALLOC_MINALIGN, -1);
 
 	if (c) {
-		c->name = name;
+		c->name = kstrdup(name, GFP_KERNEL);
+		if (!c->name) {
+			slob_free(c, sizeof(struct kmem_cache));
+			c = NULL;
+			goto out;
+		}
 		c->size = size;
 		if (flags & SLAB_DESTROY_BY_RCU) {
 			/* leave room for rcu footer at the end of object */
@@ -589,7 +594,9 @@ struct kmem_cache *kmem_cache_create(const char *name, size_t size,
 			c->align = ARCH_SLAB_MINALIGN;
 		if (c->align < align)
 			c->align = align;
-	} else if (flags & SLAB_PANIC)
+	}
+out:
+	if (!c && (flags & SLAB_PANIC))
 		panic("Cannot create slab cache %s\n", name);
 
 	kmemleak_alloc(c, sizeof(struct kmem_cache), 1, GFP_KERNEL);
@@ -602,6 +609,7 @@ void kmem_cache_destroy(struct kmem_cache *c)
 	kmemleak_free(c);
 	if (c->flags & SLAB_DESTROY_BY_RCU)
 		rcu_barrier();
+	kfree(c->name);
 	slob_free(c, sizeof(struct kmem_cache));
 }
 EXPORT_SYMBOL(kmem_cache_destroy);
-- 
1.7.7.6

^ permalink raw reply related	[flat|nested] 21+ messages in thread

* Re: [PATCH v2] slab+slob: dup name string
  2012-05-22  9:51 ` Glauber Costa
@ 2012-05-22 13:58   ` Christoph Lameter
  -1 siblings, 0 replies; 21+ messages in thread
From: Christoph Lameter @ 2012-05-22 13:58 UTC (permalink / raw)
  To: Glauber Costa
  Cc: linux-kernel, cgroups, linux-mm, Pekka Enberg, David Rientjes

On Tue, 22 May 2012, Glauber Costa wrote:

> [ v2: Also dup string for early caches, requested by David Rientjes ]

kstrdups that early could cause additional issues. Its better to leave
things as they were.


^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [PATCH v2] slab+slob: dup name string
@ 2012-05-22 13:58   ` Christoph Lameter
  0 siblings, 0 replies; 21+ messages in thread
From: Christoph Lameter @ 2012-05-22 13:58 UTC (permalink / raw)
  To: Glauber Costa
  Cc: linux-kernel, cgroups, linux-mm, Pekka Enberg, David Rientjes

On Tue, 22 May 2012, Glauber Costa wrote:

> [ v2: Also dup string for early caches, requested by David Rientjes ]

kstrdups that early could cause additional issues. Its better to leave
things as they were.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [PATCH v2] slab+slob: dup name string
  2012-05-22 13:58   ` Christoph Lameter
  (?)
@ 2012-05-22 15:27     ` Glauber Costa
  -1 siblings, 0 replies; 21+ messages in thread
From: Glauber Costa @ 2012-05-22 15:27 UTC (permalink / raw)
  To: Christoph Lameter
  Cc: linux-kernel, cgroups, linux-mm, Pekka Enberg, David Rientjes

On 05/22/2012 05:58 PM, Christoph Lameter wrote:
> On Tue, 22 May 2012, Glauber Costa wrote:
>
>> [ v2: Also dup string for early caches, requested by David Rientjes ]
>
> kstrdups that early could cause additional issues. Its better to leave
> things as they were.
>

For me is really all the same. But note that before those kstrdups, we 
do a bunch of kmallocs as well already. (ex:

/* 4) Replace the bootstrap head arrays */
{
	struct array_cache *ptr;

	ptr = kmalloc(sizeof(struct arraycache_init), GFP_NOWAIT);

Which other point of issues do you see besides the memory allocation 
done by strdup?

I agree with your comment that we shouldn't worry about those caches, 
because only init code uses it.

Weather or not David's concern of wanting to delete those caches some 
day is valid, I'll leave up to you guys to decide


^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [PATCH v2] slab+slob: dup name string
@ 2012-05-22 15:27     ` Glauber Costa
  0 siblings, 0 replies; 21+ messages in thread
From: Glauber Costa @ 2012-05-22 15:27 UTC (permalink / raw)
  To: Christoph Lameter
  Cc: linux-kernel, cgroups, linux-mm, Pekka Enberg, David Rientjes

On 05/22/2012 05:58 PM, Christoph Lameter wrote:
> On Tue, 22 May 2012, Glauber Costa wrote:
>
>> [ v2: Also dup string for early caches, requested by David Rientjes ]
>
> kstrdups that early could cause additional issues. Its better to leave
> things as they were.
>

For me is really all the same. But note that before those kstrdups, we 
do a bunch of kmallocs as well already. (ex:

/* 4) Replace the bootstrap head arrays */
{
	struct array_cache *ptr;

	ptr = kmalloc(sizeof(struct arraycache_init), GFP_NOWAIT);

Which other point of issues do you see besides the memory allocation 
done by strdup?

I agree with your comment that we shouldn't worry about those caches, 
because only init code uses it.

Weather or not David's concern of wanting to delete those caches some 
day is valid, I'll leave up to you guys to decide

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [PATCH v2] slab+slob: dup name string
@ 2012-05-22 15:27     ` Glauber Costa
  0 siblings, 0 replies; 21+ messages in thread
From: Glauber Costa @ 2012-05-22 15:27 UTC (permalink / raw)
  To: Christoph Lameter
  Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA,
	cgroups-u79uwXL29TY76Z2rM5mHXA, linux-mm-Bw31MaZKKs3YtjvyW6yDsg,
	Pekka Enberg, David Rientjes

On 05/22/2012 05:58 PM, Christoph Lameter wrote:
> On Tue, 22 May 2012, Glauber Costa wrote:
>
>> [ v2: Also dup string for early caches, requested by David Rientjes ]
>
> kstrdups that early could cause additional issues. Its better to leave
> things as they were.
>

For me is really all the same. But note that before those kstrdups, we 
do a bunch of kmallocs as well already. (ex:

/* 4) Replace the bootstrap head arrays */
{
	struct array_cache *ptr;

	ptr = kmalloc(sizeof(struct arraycache_init), GFP_NOWAIT);

Which other point of issues do you see besides the memory allocation 
done by strdup?

I agree with your comment that we shouldn't worry about those caches, 
because only init code uses it.

Weather or not David's concern of wanting to delete those caches some 
day is valid, I'll leave up to you guys to decide

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [PATCH v2] slab+slob: dup name string
  2012-05-22 15:27     ` Glauber Costa
@ 2012-05-22 17:18       ` Christoph Lameter
  -1 siblings, 0 replies; 21+ messages in thread
From: Christoph Lameter @ 2012-05-22 17:18 UTC (permalink / raw)
  To: Glauber Costa
  Cc: linux-kernel, cgroups, linux-mm, Pekka Enberg, David Rientjes

On Tue, 22 May 2012, Glauber Costa wrote:

> On 05/22/2012 05:58 PM, Christoph Lameter wrote:
> > On Tue, 22 May 2012, Glauber Costa wrote:
> >
> > > [ v2: Also dup string for early caches, requested by David Rientjes ]
> >
> > kstrdups that early could cause additional issues. Its better to leave
> > things as they were.
> >
>
> For me is really all the same. But note that before those kstrdups, we do a
> bunch of kmallocs as well already. (ex:

We check carefully and make sure those caches are present before doing
these kmallocs. See the slab bootup code. A kstrdup may take a variously
sized string and explode because the required kmalloc cache is not
present.


^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [PATCH v2] slab+slob: dup name string
@ 2012-05-22 17:18       ` Christoph Lameter
  0 siblings, 0 replies; 21+ messages in thread
From: Christoph Lameter @ 2012-05-22 17:18 UTC (permalink / raw)
  To: Glauber Costa
  Cc: linux-kernel, cgroups, linux-mm, Pekka Enberg, David Rientjes

On Tue, 22 May 2012, Glauber Costa wrote:

> On 05/22/2012 05:58 PM, Christoph Lameter wrote:
> > On Tue, 22 May 2012, Glauber Costa wrote:
> >
> > > [ v2: Also dup string for early caches, requested by David Rientjes ]
> >
> > kstrdups that early could cause additional issues. Its better to leave
> > things as they were.
> >
>
> For me is really all the same. But note that before those kstrdups, we do a
> bunch of kmallocs as well already. (ex:

We check carefully and make sure those caches are present before doing
these kmallocs. See the slab bootup code. A kstrdup may take a variously
sized string and explode because the required kmalloc cache is not
present.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [PATCH v2] slab+slob: dup name string
  2012-05-22 13:58   ` Christoph Lameter
  (?)
@ 2012-05-23  3:55     ` David Rientjes
  -1 siblings, 0 replies; 21+ messages in thread
From: David Rientjes @ 2012-05-23  3:55 UTC (permalink / raw)
  To: Christoph Lameter
  Cc: Glauber Costa, linux-kernel, cgroups, linux-mm, Pekka Enberg

On Tue, 22 May 2012, Christoph Lameter wrote:

> > [ v2: Also dup string for early caches, requested by David Rientjes ]
> 
> kstrdups that early could cause additional issues. Its better to leave
> things as they were.
> 

No, it's not, there's no reason to prevent caches created before 
g_cpucache_up <= EARLY to be destroyed because it makes a patch easier to 
implement and then leave that little gotcha as an undocumented treasure 
for someone to find when they try it later on.

I hate consistency patches like this because it could potentially fail a 
kmem_cache_create() from a sufficiently long cache name when it wouldn't 
have before, but I'm not really concerned since kmem_cache_create() will 
naturally be followed by kmem_cache_alloc() which is more likely to cause 
the oom anyway.  But it's just another waste of memory for consistency 
sake.

This is much easier to do, just statically allocate the const char *'s 
needed for the boot caches and then set their ->name's manually in 
kmem_cache_init() and then avoid the kfree() in kmem_cache_destroy() if 
the name is between &boot_cache_name[0] and &boot_cache_name[n].

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [PATCH v2] slab+slob: dup name string
@ 2012-05-23  3:55     ` David Rientjes
  0 siblings, 0 replies; 21+ messages in thread
From: David Rientjes @ 2012-05-23  3:55 UTC (permalink / raw)
  To: Christoph Lameter
  Cc: Glauber Costa, linux-kernel, cgroups, linux-mm, Pekka Enberg

On Tue, 22 May 2012, Christoph Lameter wrote:

> > [ v2: Also dup string for early caches, requested by David Rientjes ]
> 
> kstrdups that early could cause additional issues. Its better to leave
> things as they were.
> 

No, it's not, there's no reason to prevent caches created before 
g_cpucache_up <= EARLY to be destroyed because it makes a patch easier to 
implement and then leave that little gotcha as an undocumented treasure 
for someone to find when they try it later on.

I hate consistency patches like this because it could potentially fail a 
kmem_cache_create() from a sufficiently long cache name when it wouldn't 
have before, but I'm not really concerned since kmem_cache_create() will 
naturally be followed by kmem_cache_alloc() which is more likely to cause 
the oom anyway.  But it's just another waste of memory for consistency 
sake.

This is much easier to do, just statically allocate the const char *'s 
needed for the boot caches and then set their ->name's manually in 
kmem_cache_init() and then avoid the kfree() in kmem_cache_destroy() if 
the name is between &boot_cache_name[0] and &boot_cache_name[n].

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [PATCH v2] slab+slob: dup name string
@ 2012-05-23  3:55     ` David Rientjes
  0 siblings, 0 replies; 21+ messages in thread
From: David Rientjes @ 2012-05-23  3:55 UTC (permalink / raw)
  To: Christoph Lameter
  Cc: Glauber Costa, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
	cgroups-u79uwXL29TY76Z2rM5mHXA, linux-mm-Bw31MaZKKs3YtjvyW6yDsg,
	Pekka Enberg

On Tue, 22 May 2012, Christoph Lameter wrote:

> > [ v2: Also dup string for early caches, requested by David Rientjes ]
> 
> kstrdups that early could cause additional issues. Its better to leave
> things as they were.
> 

No, it's not, there's no reason to prevent caches created before 
g_cpucache_up <= EARLY to be destroyed because it makes a patch easier to 
implement and then leave that little gotcha as an undocumented treasure 
for someone to find when they try it later on.

I hate consistency patches like this because it could potentially fail a 
kmem_cache_create() from a sufficiently long cache name when it wouldn't 
have before, but I'm not really concerned since kmem_cache_create() will 
naturally be followed by kmem_cache_alloc() which is more likely to cause 
the oom anyway.  But it's just another waste of memory for consistency 
sake.

This is much easier to do, just statically allocate the const char *'s 
needed for the boot caches and then set their ->name's manually in 
kmem_cache_init() and then avoid the kfree() in kmem_cache_destroy() if 
the name is between &boot_cache_name[0] and &boot_cache_name[n].

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [PATCH v2] slab+slob: dup name string
  2012-05-23  3:55     ` David Rientjes
  (?)
@ 2012-05-23  9:25       ` Glauber Costa
  -1 siblings, 0 replies; 21+ messages in thread
From: Glauber Costa @ 2012-05-23  9:25 UTC (permalink / raw)
  To: David Rientjes
  Cc: Christoph Lameter, linux-kernel, cgroups, linux-mm, Pekka Enberg

On 05/23/2012 07:55 AM, David Rientjes wrote:
> I hate consistency patches like this because it could potentially fail a
> kmem_cache_create() from a sufficiently long cache name when it wouldn't
> have before, but I'm not really concerned since kmem_cache_create() will
> naturally be followed by kmem_cache_alloc() which is more likely to cause
> the oom anyway.  But it's just another waste of memory for consistency
> sake.
>
> This is much easier to do, just statically allocate the const char *'s
> needed for the boot caches and then set their ->name's manually in
> kmem_cache_init() and then avoid the kfree() in kmem_cache_destroy() if
> the name is between&boot_cache_name[0] and&boot_cache_name[n].

That can be done.

I'll also revisit my memcg patches to see if I can rework it so it 
doesn't care about this particular behavior. We're having a surprisingly 
difficult time reaching consensus on this, so maybe it would be better 
left untouched (if there is a way that makes sense to)

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [PATCH v2] slab+slob: dup name string
@ 2012-05-23  9:25       ` Glauber Costa
  0 siblings, 0 replies; 21+ messages in thread
From: Glauber Costa @ 2012-05-23  9:25 UTC (permalink / raw)
  To: David Rientjes
  Cc: Christoph Lameter, linux-kernel, cgroups, linux-mm, Pekka Enberg

On 05/23/2012 07:55 AM, David Rientjes wrote:
> I hate consistency patches like this because it could potentially fail a
> kmem_cache_create() from a sufficiently long cache name when it wouldn't
> have before, but I'm not really concerned since kmem_cache_create() will
> naturally be followed by kmem_cache_alloc() which is more likely to cause
> the oom anyway.  But it's just another waste of memory for consistency
> sake.
>
> This is much easier to do, just statically allocate the const char *'s
> needed for the boot caches and then set their ->name's manually in
> kmem_cache_init() and then avoid the kfree() in kmem_cache_destroy() if
> the name is between&boot_cache_name[0] and&boot_cache_name[n].

That can be done.

I'll also revisit my memcg patches to see if I can rework it so it 
doesn't care about this particular behavior. We're having a surprisingly 
difficult time reaching consensus on this, so maybe it would be better 
left untouched (if there is a way that makes sense to)

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [PATCH v2] slab+slob: dup name string
@ 2012-05-23  9:25       ` Glauber Costa
  0 siblings, 0 replies; 21+ messages in thread
From: Glauber Costa @ 2012-05-23  9:25 UTC (permalink / raw)
  To: David Rientjes
  Cc: Christoph Lameter, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
	cgroups-u79uwXL29TY76Z2rM5mHXA, linux-mm-Bw31MaZKKs3YtjvyW6yDsg,
	Pekka Enberg

On 05/23/2012 07:55 AM, David Rientjes wrote:
> I hate consistency patches like this because it could potentially fail a
> kmem_cache_create() from a sufficiently long cache name when it wouldn't
> have before, but I'm not really concerned since kmem_cache_create() will
> naturally be followed by kmem_cache_alloc() which is more likely to cause
> the oom anyway.  But it's just another waste of memory for consistency
> sake.
>
> This is much easier to do, just statically allocate the const char *'s
> needed for the boot caches and then set their ->name's manually in
> kmem_cache_init() and then avoid the kfree() in kmem_cache_destroy() if
> the name is between&boot_cache_name[0] and&boot_cache_name[n].

That can be done.

I'll also revisit my memcg patches to see if I can rework it so it 
doesn't care about this particular behavior. We're having a surprisingly 
difficult time reaching consensus on this, so maybe it would be better 
left untouched (if there is a way that makes sense to)

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [PATCH v2] slab+slob: dup name string
  2012-05-23  3:55     ` David Rientjes
  (?)
@ 2012-05-23 13:53       ` Christoph Lameter
  -1 siblings, 0 replies; 21+ messages in thread
From: Christoph Lameter @ 2012-05-23 13:53 UTC (permalink / raw)
  To: David Rientjes
  Cc: Glauber Costa, linux-kernel, cgroups, linux-mm, Pekka Enberg

On Tue, 22 May 2012, David Rientjes wrote:

> On Tue, 22 May 2012, Christoph Lameter wrote:
>
> > > [ v2: Also dup string for early caches, requested by David Rientjes ]
> >
> > kstrdups that early could cause additional issues. Its better to leave
> > things as they were.
> >
>
> No, it's not, there's no reason to prevent caches created before
> g_cpucache_up <= EARLY to be destroyed because it makes a patch easier to
> implement and then leave that little gotcha as an undocumented treasure
> for someone to find when they try it later on.

g_cpucache_up <= EARLY is slab bootstrap code and the system is in a
pretty fragile state. Plus the the kmalloc logic *depends* on these
caches being present. Removing those is not a good idea. The other caches
that are created at that point are needed to create more caches.

There is no reason to remove these caches.

> This is much easier to do, just statically allocate the const char *'s
> needed for the boot caches and then set their ->name's manually in
> kmem_cache_init() and then avoid the kfree() in kmem_cache_destroy() if
> the name is between &boot_cache_name[0] and &boot_cache_name[n].

Yeah that is already occurring for some of the boot caches.


^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [PATCH v2] slab+slob: dup name string
@ 2012-05-23 13:53       ` Christoph Lameter
  0 siblings, 0 replies; 21+ messages in thread
From: Christoph Lameter @ 2012-05-23 13:53 UTC (permalink / raw)
  To: David Rientjes
  Cc: Glauber Costa, linux-kernel, cgroups, linux-mm, Pekka Enberg

On Tue, 22 May 2012, David Rientjes wrote:

> On Tue, 22 May 2012, Christoph Lameter wrote:
>
> > > [ v2: Also dup string for early caches, requested by David Rientjes ]
> >
> > kstrdups that early could cause additional issues. Its better to leave
> > things as they were.
> >
>
> No, it's not, there's no reason to prevent caches created before
> g_cpucache_up <= EARLY to be destroyed because it makes a patch easier to
> implement and then leave that little gotcha as an undocumented treasure
> for someone to find when they try it later on.

g_cpucache_up <= EARLY is slab bootstrap code and the system is in a
pretty fragile state. Plus the the kmalloc logic *depends* on these
caches being present. Removing those is not a good idea. The other caches
that are created at that point are needed to create more caches.

There is no reason to remove these caches.

> This is much easier to do, just statically allocate the const char *'s
> needed for the boot caches and then set their ->name's manually in
> kmem_cache_init() and then avoid the kfree() in kmem_cache_destroy() if
> the name is between &boot_cache_name[0] and &boot_cache_name[n].

Yeah that is already occurring for some of the boot caches.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [PATCH v2] slab+slob: dup name string
@ 2012-05-23 13:53       ` Christoph Lameter
  0 siblings, 0 replies; 21+ messages in thread
From: Christoph Lameter @ 2012-05-23 13:53 UTC (permalink / raw)
  To: David Rientjes
  Cc: Glauber Costa, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
	cgroups-u79uwXL29TY76Z2rM5mHXA, linux-mm-Bw31MaZKKs3YtjvyW6yDsg,
	Pekka Enberg

On Tue, 22 May 2012, David Rientjes wrote:

> On Tue, 22 May 2012, Christoph Lameter wrote:
>
> > > [ v2: Also dup string for early caches, requested by David Rientjes ]
> >
> > kstrdups that early could cause additional issues. Its better to leave
> > things as they were.
> >
>
> No, it's not, there's no reason to prevent caches created before
> g_cpucache_up <= EARLY to be destroyed because it makes a patch easier to
> implement and then leave that little gotcha as an undocumented treasure
> for someone to find when they try it later on.

g_cpucache_up <= EARLY is slab bootstrap code and the system is in a
pretty fragile state. Plus the the kmalloc logic *depends* on these
caches being present. Removing those is not a good idea. The other caches
that are created at that point are needed to create more caches.

There is no reason to remove these caches.

> This is much easier to do, just statically allocate the const char *'s
> needed for the boot caches and then set their ->name's manually in
> kmem_cache_init() and then avoid the kfree() in kmem_cache_destroy() if
> the name is between &boot_cache_name[0] and &boot_cache_name[n].

Yeah that is already occurring for some of the boot caches.

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [PATCH v2] slab+slob: dup name string
  2012-05-23 13:53       ` Christoph Lameter
@ 2012-05-24  1:01         ` David Rientjes
  -1 siblings, 0 replies; 21+ messages in thread
From: David Rientjes @ 2012-05-24  1:01 UTC (permalink / raw)
  To: Christoph Lameter
  Cc: Glauber Costa, linux-kernel, cgroups, linux-mm, Pekka Enberg

On Wed, 23 May 2012, Christoph Lameter wrote:

> > No, it's not, there's no reason to prevent caches created before
> > g_cpucache_up <= EARLY to be destroyed because it makes a patch easier to
> > implement and then leave that little gotcha as an undocumented treasure
> > for someone to find when they try it later on.
> 
> g_cpucache_up <= EARLY is slab bootstrap code and the system is in a
> pretty fragile state. Plus the the kmalloc logic *depends* on these
> caches being present. Removing those is not a good idea. The other caches
> that are created at that point are needed to create more caches.
> 
> There is no reason to remove these caches.
> 

Yes, we know that we don't want to remove the caches that are currently 
created in kmem_cache_init(), it would be a pretty stupid thing to do.  
I'm talking about the possibility of creating additional caches while 
g_cpucache_up <= EARLY in the future and then finding that you can't 
destroy them because of this string allocation.  I don't think it's too 
difficult to statically allocate space for these names and then test for 
it before doing kfree() in kmem_cache_destroy(), it's not performance 
critical.

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [PATCH v2] slab+slob: dup name string
@ 2012-05-24  1:01         ` David Rientjes
  0 siblings, 0 replies; 21+ messages in thread
From: David Rientjes @ 2012-05-24  1:01 UTC (permalink / raw)
  To: Christoph Lameter
  Cc: Glauber Costa, linux-kernel, cgroups, linux-mm, Pekka Enberg

On Wed, 23 May 2012, Christoph Lameter wrote:

> > No, it's not, there's no reason to prevent caches created before
> > g_cpucache_up <= EARLY to be destroyed because it makes a patch easier to
> > implement and then leave that little gotcha as an undocumented treasure
> > for someone to find when they try it later on.
> 
> g_cpucache_up <= EARLY is slab bootstrap code and the system is in a
> pretty fragile state. Plus the the kmalloc logic *depends* on these
> caches being present. Removing those is not a good idea. The other caches
> that are created at that point are needed to create more caches.
> 
> There is no reason to remove these caches.
> 

Yes, we know that we don't want to remove the caches that are currently 
created in kmem_cache_init(), it would be a pretty stupid thing to do.  
I'm talking about the possibility of creating additional caches while 
g_cpucache_up <= EARLY in the future and then finding that you can't 
destroy them because of this string allocation.  I don't think it's too 
difficult to statically allocate space for these names and then test for 
it before doing kfree() in kmem_cache_destroy(), it's not performance 
critical.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

^ permalink raw reply	[flat|nested] 21+ messages in thread

end of thread, other threads:[~2012-05-24  1:01 UTC | newest]

Thread overview: 21+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-05-22  9:51 [PATCH v2] slab+slob: dup name string Glauber Costa
2012-05-22  9:51 ` Glauber Costa
2012-05-22  9:51 ` Glauber Costa
2012-05-22 13:58 ` Christoph Lameter
2012-05-22 13:58   ` Christoph Lameter
2012-05-22 15:27   ` Glauber Costa
2012-05-22 15:27     ` Glauber Costa
2012-05-22 15:27     ` Glauber Costa
2012-05-22 17:18     ` Christoph Lameter
2012-05-22 17:18       ` Christoph Lameter
2012-05-23  3:55   ` David Rientjes
2012-05-23  3:55     ` David Rientjes
2012-05-23  3:55     ` David Rientjes
2012-05-23  9:25     ` Glauber Costa
2012-05-23  9:25       ` Glauber Costa
2012-05-23  9:25       ` Glauber Costa
2012-05-23 13:53     ` Christoph Lameter
2012-05-23 13:53       ` Christoph Lameter
2012-05-23 13:53       ` Christoph Lameter
2012-05-24  1:01       ` David Rientjes
2012-05-24  1:01         ` David Rientjes

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.