public inbox for linux-fsdevel@vger.kernel.org
 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: Tue, 10 Mar 2026 11:06:42 +0100	[thread overview]
Message-ID: <a61a876d-6377-4e7a-9651-e0fc05819a72@kernel.org> (raw)
In-Reply-To: <aa-PQBn5d0-U-sKg@hyeyoo>

On 3/10/26 04:25, Harry Yoo wrote:
> On Mon, Mar 09, 2026 at 03:00:17PM +0100, vbabka@kernel.org wrote:
>> 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?
> 
> To be honest, I don't a have strong opinion on that.
> 
> Is grouping by mobility (for anti-fragmentation less) important on
> SLUB_TINY systems?

Yeah, that's why "KMALLOC_RECLAIM = KMALLOC_NORMAL" there. So prioritizing
__GFP_RECLAIMABLE does nothing there, it goes to the same kmalloc_normal
cache. It only results in ignoring KMALLOC_CGROUP.
(I think in practice SLUB_TINY systems wouldn't enabled CONFIG_MEMCG either,
so it's a low priority, but still logical imho).

>> > 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
>> > Cc: stable@vger.kernel.org
>> > Signed-off-by: Harry Yoo <harry.yoo@oracle.com>
>> 
>> Added to slab/for-next-fixes, thanks!
> 
> Thanks!
> 


  reply	other threads:[~2026-03-10 10:06 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
2026-03-10  3:25       ` Harry Yoo
2026-03-10 10:06         ` vbabka [this message]
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=a61a876d-6377-4e7a-9651-e0fc05819a72@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