[BUG] WARNING in alloc_slab_obj_exts triggered by __d_alloc

[BUG] WARNING in alloc_slab_obj_exts triggered by __d_alloc

[Zw Tang]

Hi,

I encountered a WARNING in alloc_slab_obj_exts() while running a
syzkaller-generated reproducer on Linux 7.0-rc2.

The warning is triggered during dentry allocation (__d_alloc) after
mounting a crafted ext4 filesystem image.

Kernel
git tree: torvalds/linux
commit： 0031c06807cfa8aa51a759ff8aa09e1aa48149af
kernel version:Linux 7.0.0-rc2-00057-g0031c06807cf
hardware: QEMU Ubuntu 24.10

I was able to reproduce this issue reliably using the attached
reproducer.

Reproducer：
C reproducer: https://pastebin.com/raw/eHjm2Aw6
console output: https://pastebin.com/raw/FQAhquTy
kernel config: pastebin.com/raw/CnHdTQNm

The warning originates from:

mm/slub.c:2189

Call trace:

WARNING: mm/slub.c:2189 at alloc_slab_obj_exts+0x132/0x180
CPU: 0 UID: 0 PID: 699 Comm: syz.0.118

Call Trace:
 <TASK>
 __memcg_slab_post_alloc_hook+0x130/0x460 mm/memcontrol.c:3234
 memcg_slab_post_alloc_hook mm/slub.c:2464 [inline]
 slab_post_alloc_hook.constprop.0+0x9c/0xf0 mm/slub.c:4526
 slab_alloc_node.constprop.0+0xaa/0x160 mm/slub.c:4844
 __do_kmalloc_node mm/slub.c:5237 [inline]
 __kmalloc_noprof+0x82/0x200 mm/slub.c:5250
 kmalloc_noprof include/linux/slab.h:954 [inline]
 __d_alloc+0x235/0x2f0 fs/dcache.c:1757
 d_alloc_pseudo+0x1d/0x70 fs/dcache.c:1871
 alloc_path_pseudo fs/file_table.c:364 [inline]
 alloc_file_pseudo+0x64/0x140 fs/file_table.c:380
 __shmem_file_setup+0x136/0x270 mm/shmem.c:5863
 memfd_alloc_file+0x81/0x240 mm/memfd.c:471
 __do_sys_memfd_create mm/memfd.c:522 [inline]
 __se_sys_memfd_create mm/memfd.c:505 [inline]
 __x64_sys_memfd_create+0x205/0x440 mm/memfd.c:505
 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
 do_syscall_64+0x11d/0x5a0 arch/x86/entry/syscall_64.c:94
 entry_SYSCALL_64_after_hwframe+0x4b/0x53

The issue happens after mounting an ext4 filesystem image via a loop
device created from a compressed image in the reproducer.

Relevant kernel messages:

EXT4-fs (loop0): mounted filesystem
00000000-0000-0000-0000-000000000000 r/w without journal.
EXT4-fs (loop3): Delayed block allocation failed for inode 18 at
logical offset 768 with max blocks 2 with error 28
EXT4-fs (loop3): This should not happen!! Data will be lost

The WARNING occurs in alloc_slab_obj_exts(), which is related to slab
object extension allocation.

This may indicate a slab metadata inconsistency triggered by the
filesystem state.

Please let me know if additional debugging information would help.

Thanks.
Zw Tang

Re: [BUG] WARNING in alloc_slab_obj_exts triggered by __d_alloc

[Harry Yoo]

On Mon, Mar 09, 2026 at 11:14:58AM +0800, Zw Tang wrote:
> Hi,
> 
> I encountered a WARNING in alloc_slab_obj_exts() while running a
> syzkaller-generated reproducer on Linux 7.0-rc2.
> 
> The warning is triggered during dentry allocation (__d_alloc) after
> mounting a crafted ext4 filesystem image.
> 
> Kernel
> git tree: torvalds/linux
> commit： 0031c06807cfa8aa51a759ff8aa09e1aa48149af
> kernel version:Linux 7.0.0-rc2-00057-g0031c06807cf
> hardware: QEMU Ubuntu 24.10
> 
> I was able to reproduce this issue reliably using the attached
> reproducer.

Hi, thanks for the report!

> Reproducer：
> C reproducer: https://pastebin.com/raw/eHjm2Aw6
> console output: https://pastebin.com/raw/FQAhquTy
> kernel config: pastebin.com/raw/CnHdTQNm

a few notable config options:

CONFIG_SLUB_TINY=y (which implies KMALLOC_RECLAIM = KMALLOC_NORMAL)
# CONFIG_MEM_ALLOC_PROFILING is not set
CONFIG_MEMCG=y

and also random kmalloc cache feature is not enabled.

> The warning originates from:
> 
> mm/slub.c:2189
>
> Call trace:
> 
> WARNING: mm/slub.c:2189 at alloc_slab_obj_exts+0x132/0x180
> CPU: 0 UID: 0 PID: 699 Comm: syz.0.118

The triggered warning is:

VM_WARN_ON_ONCE(virt_to_slab(vec) != NULL &&
		virt_to_slab(vec)->slab_cache == s);

which means we may be creating a never-freed slab due to recursion.

obj_exts_alloc_size() is supposed to prevent this but it didn't.
Let's see why.

> Call Trace:
>  <TASK>
>  __memcg_slab_post_alloc_hook+0x130/0x460 mm/memcontrol.c:3234
>  memcg_slab_post_alloc_hook mm/slub.c:2464 [inline]
>  slab_post_alloc_hook.constprop.0+0x9c/0xf0 mm/slub.c:4526
>  slab_alloc_node.constprop.0+0xaa/0x160 mm/slub.c:4844
>  __do_kmalloc_node mm/slub.c:5237 [inline]
>  __kmalloc_noprof+0x82/0x200 mm/slub.c:5250
>  kmalloc_noprof include/linux/slab.h:954 [inline]
>  __d_alloc+0x235/0x2f0 fs/dcache.c:1757

The gfp flag used by __d_alloc() is
GFP_KERNEL_ACCOUNT | __GFP_RECLAIMABLE.

Looking at kmalloc_type(), when both __GFP_RECLAIMABLE and __GFP_ACCOUNT
flags are specified, __GFP_RECLAIMABLE has a higher priority.

That said, obj_exts_alloc_size() needs to handle CONFIG_SLUB_TINY
(KMALLOC_RECLAIM = KMALLOC_NORMAL) properly.

in obj_exts_alloc_size():
>        /*
>         * slabobj_ext array for KMALLOC_CGROUP allocations
>         * are served from KMALLOC_NORMAL caches.
>         */
>        if (!mem_alloc_profiling_enabled())
>                return sz;

I added this just to make sure we're not pessimizing when memory
profiling is not enabled. It turns out this part is incorrect,
and actually, redundant.

When memcg requested allocation, the snippet assumes that it would be
KMALLOC_CGROUP, but it turns out there is an exception:
SLUB_TINY with __GFP_ACCOUNT and __GFP_RECLAIMABLE specified.

This should be properly handled by:

>        if (!is_kmalloc_normal(s))
>                return sz;

I think this should work:

diff --git a/mm/slub.c b/mm/slub.c
index 0c906fefc31b..4759fe6aa60e 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;



>  d_alloc_pseudo+0x1d/0x70 fs/dcache.c:1871
>  alloc_path_pseudo fs/file_table.c:364 [inline]
>  alloc_file_pseudo+0x64/0x140 fs/file_table.c:380
>  __shmem_file_setup+0x136/0x270 mm/shmem.c:5863
>  memfd_alloc_file+0x81/0x240 mm/memfd.c:471
>  __do_sys_memfd_create mm/memfd.c:522 [inline]
>  __se_sys_memfd_create mm/memfd.c:505 [inline]
>  __x64_sys_memfd_create+0x205/0x440 mm/memfd.c:505
>  do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
>  do_syscall_64+0x11d/0x5a0 arch/x86/entry/syscall_64.c:94
>  entry_SYSCALL_64_after_hwframe+0x4b/0x53
> 
> The issue happens after mounting an ext4 filesystem image via a loop
> device created from a compressed image in the reproducer.
> 
> Relevant kernel messages:
> 
> EXT4-fs (loop0): mounted filesystem
> 00000000-0000-0000-0000-000000000000 r/w without journal.
> EXT4-fs (loop3): Delayed block allocation failed for inode 18 at
> logical offset 768 with max blocks 2 with error 28
> EXT4-fs (loop3): This should not happen!! Data will be lost
> 
> The WARNING occurs in alloc_slab_obj_exts(), which is related to slab
> object extension allocation.
> 
> This may indicate a slab metadata inconsistency triggered by the
> filesystem state.
> 
> Please let me know if additional debugging information would help.
> 
> Thanks.
> Zw Tang

-- 
Cheers,
Harry / Hyeonggon

[PATCH] mm/slab: fix an incorrect check in obj_exts_alloc_size()

[Harry Yoo]

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.

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>
---

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
-- 
2.43.0

Re: [PATCH] mm/slab: fix an incorrect check in obj_exts_alloc_size()

[vbabka]

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

Re: [PATCH] mm/slab: fix an incorrect check in obj_exts_alloc_size()

[Harry Yoo]

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?

> > 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!

-- 
Cheers,
Harry / Hyeonggon

Re: [PATCH] mm/slab: fix an incorrect check in obj_exts_alloc_size()

[vbabka]

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!
> 

Re: [PATCH] mm/slab: fix an incorrect check in obj_exts_alloc_size()

[Harry Yoo]

On Mon, Mar 09, 2026 at 04:22:19PM +0900, 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.
> 
> 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>
> ---
> 
> Zw Tang, could you please confirm that the warning disappears
> on your test environment, with this patch applied?

Oops, I think I saw Zw Tang's Tested-by: (thanks!), but appearently
it's not sent to linux-mm. Could you please add your Tested-by:
by replying to all, again?

-- 
Cheers,
Harry / Hyeonggon

Re: [PATCH] mm/slab: fix an incorrect check in obj_exts_alloc_size()

[Zw Tang]

Hi Harry,

Thanks for the patch.

I tested it on my environment with the original syzkaller reproducer,
and the warning no longer reproduces after applying the patch.

Kernel version tested: v7.0-rc2

Tested-by: Zw Tang shicenci@gmail.com

Best regards,
Zw Tang

Harry Yoo <harry.yoo@oracle.com> 于2026年3月9日周一 15:22写道：
>
> 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.
>
> 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>
> ---
>
> 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
> --
> 2.43.0
>

Re: [PATCH] mm/slab: fix an incorrect check in obj_exts_alloc_size()

[vbabka]

On 3/10/26 04:40, Zw Tang wrote:
> Hi Harry,
> 
> Thanks for the patch.
> 
> I tested it on my environment with the original syzkaller reproducer,
> and the warning no longer reproduces after applying the patch.
> 
> Kernel version tested: v7.0-rc2
> 
> Tested-by: Zw Tang shicenci@gmail.com

Thanks!