Re: [PATCH] mm: use unique zsmalloc caches names

[Sergey Senozhatsky]

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.