linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: vbabka@kernel.org
To: Harry Yoo <harry.yoo@oracle.com>
Cc: adilger.kernel@dilger.ca, akpm@linux-foundation.org,
	cgroups@vger.kernel.org, hannes@cmpxchg.org, hao.li@linux.dev,
	linux-ext4@vger.kernel.org, linux-fsdevel@vger.kernel.org,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org,
	shicenci@gmail.com, cl@gentwo.org, rientjes@google.com,
	roman.gushchin@linux.dev, viro@zeniv.linux.org.uk,
	surenb@google.com, stable@vger.kernel.org
Subject: Re: [PATCH] mm/slab: fix an incorrect check in obj_exts_alloc_size()
Date: Mon, 9 Mar 2026 15:00:17 +0100	[thread overview]
Message-ID: <0a25d83b-c6ea-4230-a89d-1f496b91764c@kernel.org> (raw)
In-Reply-To: <20260309072219.22653-1-harry.yoo@oracle.com>

On 3/9/26 08:22, Harry Yoo wrote:
> obj_exts_alloc_size() prevents recursive allocation of slabobj_ext
> array from the same cache, to avoid creating slabs that are never freed.
> 
> There is one mistake that returns the original size when memory
> allocation profiling is disabled. The assumption was that
> memcg-triggered slabobj_ext allocation is always served from
> KMALLOC_CGROUP type. But this is wrong [1]: when the caller specifies
> both __GFP_RECLAIMABLE and __GFP_ACCOUNT with SLUB_TINY enabled, the
> allocation is served from normal kmalloc. This is because kmalloc_type()
> prioritizes __GFP_RECLAIMABLE over __GFP_ACCOUNT, and SLUB_TINY aliases
> KMALLOC_RECLAIM with KMALLOC_NORMAL.

Hm that's suboptimal (leads to sparsely used obj_exts in normal kmalloc
slabs) and maybe separately from this hotfix we could make sure that with
SLUB_TINY, __GFP_ACCOUNT is preferred going forward?

> As a result, the recursion guard is bypassed and the problematic slabs
> can be created. Fix this by removing the mem_alloc_profiling_enabled()
> check entirely. The remaining is_kmalloc_normal() check is still
> sufficient to detect whether the cache is of KMALLOC_NORMAL type and
> avoid bumping the size if it's not.
> 
> Without SLUB_TINY, no functional change intended.
> With SLUB_TINY, allocations with __GFP_ACCOUNT|__GFP_RECLAIMABLE
> now allocate a larger array if the sizes equal.
> 
> Reported-by: Zw Tang <shicenci@gmail.com>
> Fixes: 280ea9c3154b ("mm/slab: avoid allocating slabobj_ext array from its own slab")
> Closes: https://lore.kernel.org/linux-mm/CAPHJ_VKuMKSke8b11AZQw1PTSFN4n2C0gFxC6xGOG0ZLHgPmnA@mail.gmail.com [1]
> Cc: stable@vger.kernel.org
> Signed-off-by: Harry Yoo <harry.yoo@oracle.com>

Added to slab/for-next-fixes, thanks!

> ---
> 
> Zw Tang, could you please confirm that the warning disappears
> on your test environment, with this patch applied?
> 
>  mm/slub.c | 7 -------
>  1 file changed, 7 deletions(-)
> 
> diff --git a/mm/slub.c b/mm/slub.c
> index 20cb4f3b636d..6371838d2352 100644
> --- a/mm/slub.c
> +++ b/mm/slub.c
> @@ -2119,13 +2119,6 @@ static inline size_t obj_exts_alloc_size(struct kmem_cache *s,
>  	size_t sz = sizeof(struct slabobj_ext) * slab->objects;
>  	struct kmem_cache *obj_exts_cache;
>  
> -	/*
> -	 * slabobj_ext array for KMALLOC_CGROUP allocations
> -	 * are served from KMALLOC_NORMAL caches.
> -	 */
> -	if (!mem_alloc_profiling_enabled())
> -		return sz;
> -
>  	if (sz > KMALLOC_MAX_CACHE_SIZE)
>  		return sz;
>  
> 
> base-commit: 6432f15c818cb30eec7c4ca378ecdebd9796f741



  reply	other threads:[~2026-03-09 14:00 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-03-09  3:14 [BUG] WARNING in alloc_slab_obj_exts triggered by __d_alloc Zw Tang
2026-03-09  4:33 ` Harry Yoo
2026-03-09  7:22   ` [PATCH] mm/slab: fix an incorrect check in obj_exts_alloc_size() Harry Yoo
2026-03-09 14:00     ` vbabka [this message]
2026-03-10  3:25       ` Harry Yoo
2026-03-10 10:06         ` vbabka
2026-03-10  3:29     ` Harry Yoo
2026-03-10  3:40     ` Zw Tang
2026-03-10 10:02       ` vbabka

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=0a25d83b-c6ea-4230-a89d-1f496b91764c@kernel.org \
    --to=vbabka@kernel.org \
    --cc=adilger.kernel@dilger.ca \
    --cc=akpm@linux-foundation.org \
    --cc=cgroups@vger.kernel.org \
    --cc=cl@gentwo.org \
    --cc=hannes@cmpxchg.org \
    --cc=hao.li@linux.dev \
    --cc=harry.yoo@oracle.com \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=rientjes@google.com \
    --cc=roman.gushchin@linux.dev \
    --cc=shicenci@gmail.com \
    --cc=stable@vger.kernel.org \
    --cc=surenb@google.com \
    --cc=viro@zeniv.linux.org.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox