slab vs. slub kmem cache name inconsistency

slab vs. slub kmem cache name inconsistency

[Johannes Berg]

Hi,

I just noticed that slub's kmem_cache_create() will kstrdup() the name,
while slab doesn't. That's a little confusing, since when you look at
slub you can easily get away with passing a string you built on the
stack, while that will then lead to very strange results (and possibly
crashes?) with slab. The slab kernel-doc string always says this:

 * @name must be valid until the cache is destroyed. This implies that
 * the module calling this has to destroy the cache before getting unloaded.

Is there any reason for this difference, or should slab also kstrdup(),
or should slub not do it? Or maybe slub should have a "oops, name is on
stack" warning/check?

johannes

--
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/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: slab vs. slub kmem cache name inconsistency

[JoonSoo Kim]

Hi, Johannes.

2012/10/2 Johannes Berg <johannes@sipsolutions.net>:
> Hi,
>
> I just noticed that slub's kmem_cache_create() will kstrdup() the name,
> while slab doesn't. That's a little confusing, since when you look at
> slub you can easily get away with passing a string you built on the
> stack, while that will then lead to very strange results (and possibly
> crashes?) with slab.

As far as I know, this issue is already fixed. However, fix for this
is not merged into mainline yet.
You can find the fix in common_for_cgroups branch of Pekka's git tree.

git://git.kernel.org/pub/scm/linux/kernel/git/penberg/linux.git
slab/common-for-cgroups

--
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/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: slab vs. slub kmem cache name inconsistency

[Johannes Berg]

Hi,

> > I just noticed that slub's kmem_cache_create() will kstrdup() the name,
> > while slab doesn't. That's a little confusing, since when you look at
> > slub you can easily get away with passing a string you built on the
> > stack, while that will then lead to very strange results (and possibly
> > crashes?) with slab.
> 
> As far as I know, this issue is already fixed. However, fix for this
> is not merged into mainline yet.
> You can find the fix in common_for_cgroups branch of Pekka's git tree.
> 
> git://git.kernel.org/pub/scm/linux/kernel/git/penberg/linux.git
> slab/common-for-cgroups

Cool, yes, we have a commit there which addresses this:

http://git.kernel.org/?p=linux/kernel/git/penberg/linux.git;a=commit;h=db265eca77000c5dafc5608975afe8dafb2a02d5

Thanks!

johannes

--
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/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: slab vs. slub kmem cache name inconsistency

[Christoph Lameter]

This should be fixed the merge window for 3.7. All allocators will do a
kstrdup then.

On Tue, 2 Oct 2012, Johannes Berg wrote:

> Hi,
>
> I just noticed that slub's kmem_cache_create() will kstrdup() the name,
> while slab doesn't. That's a little confusing, since when you look at
> slub you can easily get away with passing a string you built on the
> stack, while that will then lead to very strange results (and possibly
> crashes?) with slab. The slab kernel-doc string always says this:
>
>  * @name must be valid until the cache is destroyed. This implies that
>  * the module calling this has to destroy the cache before getting unloaded.
>
> Is there any reason for this difference, or should slab also kstrdup(),
> or should slub not do it? Or maybe slub should have a "oops, name is on
> stack" warning/check?
>
> johannes
>

--
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/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>