[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20240906034522.GA2413563@google.com>
Date: Fri, 6 Sep 2024 12:45:22 +0900
From: Sergey Senozhatsky <senozhatsky@...omium.org>
To: Andrew Morton <akpm@...ux-foundation.org>
Cc: Sergey Senozhatsky <senozhatsky@...omium.org>,
Minchan Kim <minchan@...nel.org>, linux-mm@...ck.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH] mm: use unique zsmalloc caches names
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.
Powered by blists - more mailing lists