On (24/09/05 14:52), Andrew Morton wrote:
> > Each zsmalloc pool maintains several named kmem-caches for
> > zs_handle-s and zspage-s. On a system with multiple zsmalloc
> > pools and CONFIG_DEBUG_VM this triggers kmem_cache_sanity_check():
> >
> > kmem_cache of name 'zspage' already exists
> > WARNING: at mm/slab_common.c:108 do_kmem_cache_create_usercopy+0xb5/0x310
> > ...
> >
> > kmem_cache of name 'zs_handle' already exists
> > WARNING: at mm/slab_common.c:108 do_kmem_cache_create_usercopy+0xb5/0x310
> > ...
>
> This is old code. Did something recently change to trigger this warning?
The kmem_cache WARN_ON() seems to be a new thing 4c39529663b93
and I think for the past week or so my test box has been running
with DEBUG_VM disabled.
[..]
> > static int create_cache(struct zs_pool *pool)
> > {
> > - pool->handle_cachep = kmem_cache_create("zs_handle", ZS_HANDLE_SIZE,
> > - 0, 0, NULL);
> > + char name[32];
> > +
> > + snprintf(name, sizeof(name), "zs_handle-%s", pool->name);
>
> Always scary seeing code making such assumptions about it arguments in
> this fashion. Can we use kasprintf() and sleep well at night?
Sure, I'll switch to kasprintf() "pillow" in v2.
[..]
> > if (!pool->zspage_cachep) {
> > kmem_cache_destroy(pool->handle_cachep);
> > pool->handle_cachep = NULL;
>
> I guess we want to backport this into earlier kernels? If so, what
> would be a suitable Fixes:?
So this doesn't affect zsmalloc, it's only some user-space tools that
can get confused. The code in question has been around since forever.
The first kmem-cache has been introduced by 2e40e163a25a in 2015.
I'll add Fixes: 2e40e163a25af3 in v2, but I'm not certain if we are
in urge to backport anything.
