codetag: debug: Handle existing CODETAG_EMPTY in mark_objexts_empty for slabobj_ext

PATCH Superseded Hao Ge 2 participants 6 messages Oct 27, 2025 – Oct 28, 2025

Subsystems (2)

Memory management Slab allocator

lore

Share & tools

lore

Hao Ge

author

2025-10-27 08:53 UTC #0 lore raw

PATCH 1/1 codetag: debug: Handle existing CODETAG_EMPTY in mark_objexts_empty for slabobj_ext

From: Hao Ge <[email protected]>

Even though obj_exts was created with the __GFP_NO_OBJ_EXT flag, objects in the same slab may have their extensions allocated via alloc_slab_obj_exts, and handle_failed_objexts_alloc may be called within alloc_slab_obj_exts to set their codetag to CODETAG_EMPTY.

Therefore, both NULL and CODETAG_EMPTY are valid for the codetag of slabobj_ext, as we do not need to re-set it to CODETAG_EMPTY if it is already CODETAG_EMPTY. It also resolves the warning triggered when the codetag is CODETAG_EMPTY during slab freeing.

Fixes 09c46563ff6d ("codetag: debug: introduce OBJEXTS_ALLOC_FAIL to mark failed slab_ext allocations")

Signed-off-by Hao Ge <[email protected]>

---
 mm/slub.c | 12 +++++++++++-
 1 file changed, 11 insertions(+), 1 deletion(-)

mm/slub.c +11 -1

index d4367f25b20d..cda8f75b72e7 100644
@@ -2046,7 +2046,17 @@ static inline void mark_objexts_empty(struct slabobj_ext *obj_exts)
 	if (slab_exts) {
 		unsigned int offs = obj_to_index(obj_exts_slab->slab_cache,
 						 obj_exts_slab, obj_exts);
-		/* codetag should be NULL */
+
+		/*
+		 * codetag should be either NULL or CODETAG_EMPTY.
+		 * When the same slab calls handle_failed_objexts_alloc,
+		 * it will set us to CODETAG_EMPTY.
+		 *
+		 * If codetag is already CODETAG_EMPTY, no action is needed here.
+		 */
+		if (unlikely(is_codetag_empty(&slab_exts[offs].ref)))
+			return;
+
 		WARN_ON(slab_exts[offs].ref.ct);
 		set_codetag_empty(&slab_exts[offs].ref);
 	}

Signature · 1 line

2.25.1

Suren Baghdasaryan

2025-10-27 19:44 UTC #1 lore raw

Quoted 8 lines · Hao Ge

From: Hao Ge <[email protected]>
Even though obj_exts was created with the __GFP_NO_OBJ_EXT flag, objects in the same slab may have their extensions allocated via alloc_slab_obj_exts, and handle_failed_objexts_alloc may be called within alloc_slab_obj_exts to set their codetag to CODETAG_EMPTY.

Quoted 4 lines

Therefore, both NULL and CODETAG_EMPTY are valid for the codetag of slabobj_ext, as we do not need to re-set it to CODETAG_EMPTY if it is already CODETAG_EMPTY. It also resolves the warning triggered when the codetag is CODETAG_EMPTY during slab freeing.

I'm not sure what scenario leads to handle_failed_objexts_alloc() and mark_objexts_empty() being used against the same codetag reference. Could you please explain the exact scenario you hit?

handle_failed_objexts_alloc() assigns CODETAG_EMPTY to the elements of the obj_exts vector while mark_objexts_empty() assigns CODETAG_EMPTY to the obj_ext of the obj_exts vector itself. In what case do these two calls operate on the same reference?

Quoted 33 lines

Fixes 09c46563ff6d ("codetag: debug: introduce OBJEXTS_ALLOC_FAIL to mark failed slab_ext allocations")

Signed-off-by Hao Ge <[email protected]>

---
 mm/slub.c | 12 +++++++++++-
 1 file changed, 11 insertions(+), 1 deletion(-)

mm/slub.c +11 -2

index d4367f25b20d..cda8f75b72e7 100644
@@ -2046,7 +2046,17 @@ static inline void mark_objexts_empty(struct slabobj_ext *obj_exts)
        if (slab_exts) {
                unsigned int offs = obj_to_index(obj_exts_slab->slab_cache,
                                                 obj_exts_slab, obj_exts);
-               /* codetag should be NULL */
+
+               /*
+                * codetag should be either NULL or CODETAG_EMPTY.
+                * When the same slab calls handle_failed_objexts_alloc,
+                * it will set us to CODETAG_EMPTY.
+                *
+                * If codetag is already CODETAG_EMPTY, no action is needed here.
+                */
+               if (unlikely(is_codetag_empty(&slab_exts[offs].ref)))
+                       return;
+
                WARN_ON(slab_exts[offs].ref.ct);
                set_codetag_empty(&slab_exts[offs].ref);
        }
--

2.25.1

Hao Ge

author

2025-10-28 01:31 UTC #2 lore raw

Hi Suren

Quoted 12 lines · Suren Baghdasaryan

Quoted 11 lines · Hao Ge
From: Hao Ge <[email protected]>
Even though obj_exts was created with the __GFP_NO_OBJ_EXT flag, objects in the same slab may have their extensions allocated via alloc_slab_obj_exts, and handle_failed_objexts_alloc may be called within alloc_slab_obj_exts to set their codetag to CODETAG_EMPTY.
Therefore, both NULL and CODETAG_EMPTY are valid for the codetag of slabobj_ext, as we do not need to re-set it to CODETAG_EMPTY if it is already CODETAG_EMPTY. It also resolves the warning triggered when the codetag is CODETAG_EMPTY during slab freeing.

Quoted 8 lines

I'm not sure what scenario leads to handle_failed_objexts_alloc() and mark_objexts_empty() being used against the same codetag reference. Could you please explain the exact scenario you hit?
handle_failed_objexts_alloc() assigns CODETAG_EMPTY to the elements of the obj_exts vector while mark_objexts_empty() assigns CODETAG_EMPTY to the obj_ext of the obj_exts vector itself. In what case do these two calls operate on the same reference?

This issue also occurred during our memory stress testing.

I apologize for the incorrect description in my commit message:

The possibility of its occurrence should be as follows:

When a slab allocates a slabobj_ext, the slab to which this slabobj_ext belongs may have already allocated its own slabobj_ext

and called handle_failed_objexts_alloc. That is to say, the codetag of this slabobj_ext has been set to CODETAG_EMPTY.

To quickly detect this WARN, I modified the code from:WARN_ON(slab_exts[offs].ref.ct) to WARN_ON(slab_exts[offs].ref.ct == 1);

We then obtained this message:

[21630.898561] ------------[ cut here ]------------
[21630.898596] kernel BUG at mm/slub.c:2050!
[21630.898611] Internal error: Oops - BUG: 00000000f2000800 [#1] SMP
[21630.900372] Modules linked in: squashfs isofs vfio_iommu_type1 vhost_vsock vfio vhost_net vmw_vsock_virtio_transport_common vhost tap vhost_iotlb iommufd vsock binfmt_misc nfsv3 nfs_acl nfs lockd grace netfs tls rds dns_resolver tun brd overlay ntfs3 exfat btrfs blake2b_generic xor xor_neon raid6_pq loop sctp ip6_udp_tunnel udp_tunnel nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 nf_tables rfkill ip_set sunrpc vfat fat joydev sg sch_fq_codel nfnetlink virtio_gpu sr_mod cdrom drm_client_lib virtio_dma_buf drm_shmem_helper drm_kms_helper drm ghash_ce backlight virtio_net virtio_blk virtio_scsi net_failover virtio_console failover virtio_mmio dm_mirror dm_region_hash dm_log dm_multipath dm_mod fuse i2c_dev virtio_pci virtio_pci_legacy_dev virtio_pci_modern_dev virtio virtio_ring autofs4 aes_neon_bs aes_ce_blk [last unloaded: hwpoison_inject]
[21630.909177] CPU: 3 UID: 0 PID: 3787 Comm: kylin-process-m Kdump: loaded Tainted: G        W           6.18.0-rc1+ #74 PREEMPT(voluntary)
[21630.910495] Tainted: [W]=WARN
[21630.910867] Hardware name: QEMU KVM Virtual Machine, BIOS unknown 2/2/2022
[21630.911625] pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[21630.912392] pc : __free_slab+0x228/0x250
[21630.912868] lr : __free_slab+0x18c/0x250[21630.913334] sp : ffff8000a02f73e0
[21630.913830] x29: ffff8000a02f73e0 x28: fffffdffc43fc800 x27: ffff0000c0011c40
[21630.914677] x26: ffff0000c000cac0 x25: ffff00010fe5e5f0 x24: ffff000102199b40
[21630.915469] x23: 0000000000000003 x22: 0000000000000003 x21: ffff0000c0011c40
[21630.916259] x20: fffffdffc4086600 x19: fffffdffc43fc800 x18: 0000000000000000
[21630.917048] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000
[21630.917837] x14: 0000000000000000 x13: 0000000000000000 x12: ffff70001405ee66
[21630.918640] x11: 1ffff0001405ee65 x10: ffff70001405ee65 x9 : ffff800080a295dc
[21630.919442] x8 : ffff8000a02f7330 x7 : 0000000000000000 x6 : 0000000000003000
[21630.920232] x5 : 0000000024924925 x4 : 0000000000000001 x3 : 0000000000000007
[21630.921021] x2 : 0000000000001b40 x1 : 000000000000001f x0 : 0000000000000001
[21630.921810] Call trace:
[21630.922130]  __free_slab+0x228/0x250 (P)
[21630.922669]  free_slab+0x38/0x118
[21630.923079]  free_to_partial_list+0x1d4/0x340
[21630.923591]  __slab_free+0x24c/0x348
[21630.924024]  ___cache_free+0xf0/0x110
[21630.924468]  qlist_free_all+0x78/0x130
[21630.924922]  kasan_quarantine_reduce+0x114/0x148
[21630.925525]  __kasan_slab_alloc+0x7c/0xb0
[21630.926006]  kmem_cache_alloc_noprof+0x164/0x5c8
[21630.926699]  __alloc_object+0x44/0x1f8
[21630.927153]  __create_object+0x34/0xc8
[21630.927604]  kmemleak_alloc+0xb8/0xd8
[21630.928052]  kmem_cache_alloc_noprof+0x368/0x5c8
[21630.928606]  getname_flags.part.0+0xa4/0x610
[21630.929112]  getname_flags+0x80/0xd8
[21630.929557]  vfs_fstatat+0xc8/0xe0
[21630.929975]  __do_sys_newfstatat+0xa0/0x100
[21630.930469]  __arm64_sys_newfstatat+0x90/0xd8
[21630.931046]  invoke_syscall+0xd4/0x258
[21630.931685]  el0_svc_common.constprop.0+0xb4/0x240
[21630.932467]  do_el0_svc+0x48/0x68
[21630.932972]  el0_svc+0x40/0xe0
[21630.933472]  el0t_64_sync_handler+0xa0/0xe8
[21630.934151]  el0t_64_sync+0x1ac/0x1b0
[21630.934923] Code: aa1803e0 97ffef2b a9446bf9 17ffff9c (d4210000)
[21630.936461] SMP: stopping secondary CPUs
[21630.939550] Starting crashdump kernel...
[21630.940108] Bye!

Quoted 32 lines

Fixes 09c46563ff6d ("codetag: debug: introduce OBJEXTS_ALLOC_FAIL to mark failed slab_ext allocations")

Signed-off-by Hao Ge <[email protected]>

---
  mm/slub.c | 12 +++++++++++-
  1 file changed, 11 insertions(+), 1 deletion(-)

mm/slub.c +11 -2

index d4367f25b20d..cda8f75b72e7 100644
@@ -2046,7 +2046,17 @@ static inline void mark_objexts_empty(struct slabobj_ext *obj_exts)
         if (slab_exts) {
                 unsigned int offs = obj_to_index(obj_exts_slab->slab_cache,
                                                  obj_exts_slab, obj_exts);
-               /* codetag should be NULL */
+
+               /*
+                * codetag should be either NULL or CODETAG_EMPTY.
+                * When the same slab calls handle_failed_objexts_alloc,
+                * it will set us to CODETAG_EMPTY.
+                *
+                * If codetag is already CODETAG_EMPTY, no action is needed here.
+                */
+               if (unlikely(is_codetag_empty(&slab_exts[offs].ref)))
+                       return;
+
                 WARN_ON(slab_exts[offs].ref.ct);
                 set_codetag_empty(&slab_exts[offs].ref);
         }
--

2.25.1

Suren Baghdasaryan

2025-10-28 16:20 UTC #3 lore raw

Quoted 30 lines · Hao Ge

Hi Suren
Quoted 12 lines · Suren Baghdasaryan
Quoted 11 lines · Hao Ge
From: Hao Ge <[email protected]>
Even though obj_exts was created with the __GFP_NO_OBJ_EXT flag, objects in the same slab may have their extensions allocated via alloc_slab_obj_exts, and handle_failed_objexts_alloc may be called within alloc_slab_obj_exts to set their codetag to CODETAG_EMPTY.
Therefore, both NULL and CODETAG_EMPTY are valid for the codetag of slabobj_ext, as we do not need to re-set it to CODETAG_EMPTY if it is already CODETAG_EMPTY. It also resolves the warning triggered when the codetag is CODETAG_EMPTY during slab freeing.
Quoted 8 lines
I'm not sure what scenario leads to handle_failed_objexts_alloc() and mark_objexts_empty() being used against the same codetag reference. Could you please explain the exact scenario you hit?
handle_failed_objexts_alloc() assigns CODETAG_EMPTY to the elements of the obj_exts vector while mark_objexts_empty() assigns CODETAG_EMPTY to the obj_ext of the obj_exts vector itself. In what case do these two calls operate on the same reference?
This issue also occurred during our memory stress testing.
I apologize for the incorrect description in my commit message:

Quoted 7 lines

The possibility of its occurrence should be as follows:
When a slab allocates a slabobj_ext, the slab to which this slabobj_ext belongs may have already allocated its own slabobj_ext
and called handle_failed_objexts_alloc. That is to say, the codetag of this slabobj_ext has been set to CODETAG_EMPTY.

Ah, ok. Let's see if I understood this correctly. The slab from which slabobj_ext objects are allocated (let's call it slabA) tries to allocate its own slabobj_ext, fails, then succeeds and calls handle_failed_objexts_alloc() which sets all elements of its slabA->obj_exts[] to CODETAG_EMPTY. Then slabobj_ext object is allocated from slabA with __GFP_NO_OBJ_EXT, therefore it leaves slabA->obj_exts[obj_idx] intact and equal to CODETAG_EMPTY instead of NULL. At this point, slabB->obj_exts points to an object in slabA. When slabB is freed and free_slab_obj_exts() gets called to free slabB->obj_exts, it detects that slabA->obj_exts[obj_idx] is not NULL and generates this warning. In your callstack stack the freeing seems to happen inside kmem_cache_alloc_noprof() and I think that's because we lost the race and freeing the vector we allocated here:
https://elixir.bootlin.com/linux/v6.18-rc3/source/mm/slub.c#L2165 but the scenario is pretty much the same as if we didn't lose the race. The warning would happen later on I think, when we would be freeing slabB->obj_exts. The key for reproducing this is to fail allocation for a slab that is used to allocate slabobj_ext objects. Is my understanding correct?

BTW, your fix seems fine to me, I just want to understand the scenario so that we can explain it correctly.

Quoted 117 lines

To quickly detect this WARN, I modified the code from:WARN_ON(slab_exts[offs].ref.ct) to WARN_ON(slab_exts[offs].ref.ct == 1);

We then obtained this message:

[21630.898561] ------------[ cut here ]------------
[21630.898596] kernel BUG at mm/slub.c:2050!
[21630.898611] Internal error: Oops - BUG: 00000000f2000800 [#1] SMP
[21630.900372] Modules linked in: squashfs isofs vfio_iommu_type1

vhost_vsock vfio vhost_net vmw_vsock_virtio_transport_common vhost tap vhost_iotlb iommufd vsock binfmt_misc nfsv3 nfs_acl nfs lockd grace netfs tls rds dns_resolver tun brd overlay ntfs3 exfat btrfs blake2b_generic xor xor_neon raid6_pq loop sctp ip6_udp_tunnel udp_tunnel nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 nf_tables rfkill ip_set sunrpc vfat fat joydev sg sch_fq_codel nfnetlink virtio_gpu sr_mod cdrom drm_client_lib virtio_dma_buf drm_shmem_helper drm_kms_helper drm ghash_ce backlight virtio_net virtio_blk virtio_scsi net_failover virtio_console failover virtio_mmio dm_mirror dm_region_hash dm_log dm_multipath dm_mod fuse i2c_dev virtio_pci virtio_pci_legacy_dev virtio_pci_modern_dev virtio virtio_ring autofs4 aes_neon_bs aes_ce_blk [last unloaded: hwpoison_inject]

[21630.909177] CPU: 3 UID: 0 PID: 3787 Comm: kylin-process-m Kdump:
loaded Tainted: G        W           6.18.0-rc1+ #74 PREEMPT(voluntary)
[21630.910495] Tainted: [W]=WARN
[21630.910867] Hardware name: QEMU KVM Virtual Machine, BIOS unknown
2/2/2022
[21630.911625] pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS
BTYPE=--)
[21630.912392] pc : __free_slab+0x228/0x250
[21630.912868] lr : __free_slab+0x18c/0x250[21630.913334] sp :
ffff8000a02f73e0
[21630.913830] x29: ffff8000a02f73e0 x28: fffffdffc43fc800 x27:
ffff0000c0011c40
[21630.914677] x26: ffff0000c000cac0 x25: ffff00010fe5e5f0 x24:
ffff000102199b40
[21630.915469] x23: 0000000000000003 x22: 0000000000000003 x21:
ffff0000c0011c40
[21630.916259] x20: fffffdffc4086600 x19: fffffdffc43fc800 x18:
0000000000000000
[21630.917048] x17: 0000000000000000 x16: 0000000000000000 x15:
0000000000000000
[21630.917837] x14: 0000000000000000 x13: 0000000000000000 x12:
ffff70001405ee66
[21630.918640] x11: 1ffff0001405ee65 x10: ffff70001405ee65 x9 :
ffff800080a295dc
[21630.919442] x8 : ffff8000a02f7330 x7 : 0000000000000000 x6 :
0000000000003000
[21630.920232] x5 : 0000000024924925 x4 : 0000000000000001 x3 :
0000000000000007
[21630.921021] x2 : 0000000000001b40 x1 : 000000000000001f x0 :
0000000000000001
[21630.921810] Call trace:
[21630.922130]  __free_slab+0x228/0x250 (P)
[21630.922669]  free_slab+0x38/0x118
[21630.923079]  free_to_partial_list+0x1d4/0x340
[21630.923591]  __slab_free+0x24c/0x348
[21630.924024]  ___cache_free+0xf0/0x110
[21630.924468]  qlist_free_all+0x78/0x130
[21630.924922]  kasan_quarantine_reduce+0x114/0x148
[21630.925525]  __kasan_slab_alloc+0x7c/0xb0
[21630.926006]  kmem_cache_alloc_noprof+0x164/0x5c8
[21630.926699]  __alloc_object+0x44/0x1f8
[21630.927153]  __create_object+0x34/0xc8
[21630.927604]  kmemleak_alloc+0xb8/0xd8
[21630.928052]  kmem_cache_alloc_noprof+0x368/0x5c8
[21630.928606]  getname_flags.part.0+0xa4/0x610
[21630.929112]  getname_flags+0x80/0xd8
[21630.929557]  vfs_fstatat+0xc8/0xe0
[21630.929975]  __do_sys_newfstatat+0xa0/0x100
[21630.930469]  __arm64_sys_newfstatat+0x90/0xd8
[21630.931046]  invoke_syscall+0xd4/0x258
[21630.931685]  el0_svc_common.constprop.0+0xb4/0x240
[21630.932467]  do_el0_svc+0x48/0x68
[21630.932972]  el0_svc+0x40/0xe0
[21630.933472]  el0t_64_sync_handler+0xa0/0xe8
[21630.934151]  el0t_64_sync+0x1ac/0x1b0
[21630.934923] Code: aa1803e0 97ffef2b a9446bf9 17ffff9c (d4210000)
[21630.936461] SMP: stopping secondary CPUs
[21630.939550] Starting crashdump kernel...
[21630.940108] Bye!

Quoted 32 lines

Fixes 09c46563ff6d ("codetag: debug: introduce OBJEXTS_ALLOC_FAIL to mark failed slab_ext allocations")

Signed-off-by Hao Ge <[email protected]>

---
  mm/slub.c | 12 +++++++++++-
  1 file changed, 11 insertions(+), 1 deletion(-)

mm/slub.c +11 -2

index d4367f25b20d..cda8f75b72e7 100644
@@ -2046,7 +2046,17 @@ static inline void mark_objexts_empty(struct slabobj_ext *obj_exts)
         if (slab_exts) {
                 unsigned int offs = obj_to_index(obj_exts_slab->slab_cache,
                                                  obj_exts_slab, obj_exts);
-               /* codetag should be NULL */
+
+               /*
+                * codetag should be either NULL or CODETAG_EMPTY.
+                * When the same slab calls handle_failed_objexts_alloc,
+                * it will set us to CODETAG_EMPTY.
+                *
+                * If codetag is already CODETAG_EMPTY, no action is needed here.
+                */
+               if (unlikely(is_codetag_empty(&slab_exts[offs].ref)))
+                       return;
+
                 WARN_ON(slab_exts[offs].ref.ct);
                 set_codetag_empty(&slab_exts[offs].ref);
         }
--

2.25.1

Hao Ge

author

2025-10-28 16:58 UTC #4 lore raw

HI Suren

Quoted 47 lines · Suren Baghdasaryan

Quoted 28 lines · Hao Ge
Hi Suren
Quoted 12 lines · Suren Baghdasaryan
Quoted 11 lines · Hao Ge
From: Hao Ge <[email protected]>
Even though obj_exts was created with the __GFP_NO_OBJ_EXT flag, objects in the same slab may have their extensions allocated via alloc_slab_obj_exts, and handle_failed_objexts_alloc may be called within alloc_slab_obj_exts to set their codetag to CODETAG_EMPTY.
Therefore, both NULL and CODETAG_EMPTY are valid for the codetag of slabobj_ext, as we do not need to re-set it to CODETAG_EMPTY if it is already CODETAG_EMPTY. It also resolves the warning triggered when the codetag is CODETAG_EMPTY during slab freeing.
Quoted 8 lines
I'm not sure what scenario leads to handle_failed_objexts_alloc() and mark_objexts_empty() being used against the same codetag reference. Could you please explain the exact scenario you hit?
handle_failed_objexts_alloc() assigns CODETAG_EMPTY to the elements of the obj_exts vector while mark_objexts_empty() assigns CODETAG_EMPTY to the obj_ext of the obj_exts vector itself. In what case do these two calls operate on the same reference?
This issue also occurred during our memory stress testing.
I apologize for the incorrect description in my commit message:
Quoted 7 lines
The possibility of its occurrence should be as follows:
When a slab allocates a slabobj_ext, the slab to which this slabobj_ext belongs may have already allocated its own slabobj_ext
and called handle_failed_objexts_alloc. That is to say, the codetag of this slabobj_ext has been set to CODETAG_EMPTY.
Ah, ok. Let's see if I understood this correctly. The slab from which slabobj_ext objects are allocated (let's call it slabA) tries to allocate its own slabobj_ext, fails, then succeeds and calls handle_failed_objexts_alloc() which sets all elements of its slabA->obj_exts[] to CODETAG_EMPTY. Then slabobj_ext object is allocated from slabA with __GFP_NO_OBJ_EXT, therefore it leaves slabA->obj_exts[obj_idx] intact and equal to CODETAG_EMPTY instead of NULL. At this point, slabB->obj_exts points to an object in slabA. When slabB is freed and free_slab_obj_exts() gets called to free slabB->obj_exts, it detects that slabA->obj_exts[obj_idx] is not NULL and generates this warning. In your callstack stack the freeing seems

Quoted 8 lines

to happen inside kmem_cache_alloc_noprof() and I think that's because we lost the race and freeing the vector we allocated here:
https://elixir.bootlin.com/linux/v6.18-rc3/source/mm/slub.c#L2165 but the scenario is pretty much the same as if we didn't lose the race. The warning would happen later on I think, when we would be freeing slabB->obj_exts. The key for reproducing this is to fail allocation for a slab that is used to allocate slabobj_ext objects. Is my understanding correct?

Yes, your explanation is extremely detailed and thorough.

Quoted 119 lines

BTW, your fix seems fine to me, I just want to understand the scenario so that we can explain it correctly.

Quoted 116 lines

To quickly detect this WARN, I modified the code from:WARN_ON(slab_exts[offs].ref.ct) to WARN_ON(slab_exts[offs].ref.ct == 1);

We then obtained this message:

[21630.898561] ------------[ cut here ]------------
[21630.898596] kernel BUG at mm/slub.c:2050!
[21630.898611] Internal error: Oops - BUG: 00000000f2000800 [#1] SMP
[21630.900372] Modules linked in: squashfs isofs vfio_iommu_type1

[21630.909177] CPU: 3 UID: 0 PID: 3787 Comm: kylin-process-m Kdump:
loaded Tainted: G        W           6.18.0-rc1+ #74 PREEMPT(voluntary)
[21630.910495] Tainted: [W]=WARN
[21630.910867] Hardware name: QEMU KVM Virtual Machine, BIOS unknown
2/2/2022
[21630.911625] pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS
BTYPE=--)
[21630.912392] pc : __free_slab+0x228/0x250
[21630.912868] lr : __free_slab+0x18c/0x250[21630.913334] sp :
ffff8000a02f73e0
[21630.913830] x29: ffff8000a02f73e0 x28: fffffdffc43fc800 x27:
ffff0000c0011c40
[21630.914677] x26: ffff0000c000cac0 x25: ffff00010fe5e5f0 x24:
ffff000102199b40
[21630.915469] x23: 0000000000000003 x22: 0000000000000003 x21:
ffff0000c0011c40
[21630.916259] x20: fffffdffc4086600 x19: fffffdffc43fc800 x18:
0000000000000000
[21630.917048] x17: 0000000000000000 x16: 0000000000000000 x15:
0000000000000000
[21630.917837] x14: 0000000000000000 x13: 0000000000000000 x12:
ffff70001405ee66
[21630.918640] x11: 1ffff0001405ee65 x10: ffff70001405ee65 x9 :
ffff800080a295dc
[21630.919442] x8 : ffff8000a02f7330 x7 : 0000000000000000 x6 :
0000000000003000
[21630.920232] x5 : 0000000024924925 x4 : 0000000000000001 x3 :
0000000000000007
[21630.921021] x2 : 0000000000001b40 x1 : 000000000000001f x0 :
0000000000000001
[21630.921810] Call trace:
[21630.922130]  __free_slab+0x228/0x250 (P)
[21630.922669]  free_slab+0x38/0x118
[21630.923079]  free_to_partial_list+0x1d4/0x340
[21630.923591]  __slab_free+0x24c/0x348
[21630.924024]  ___cache_free+0xf0/0x110
[21630.924468]  qlist_free_all+0x78/0x130
[21630.924922]  kasan_quarantine_reduce+0x114/0x148
[21630.925525]  __kasan_slab_alloc+0x7c/0xb0
[21630.926006]  kmem_cache_alloc_noprof+0x164/0x5c8
[21630.926699]  __alloc_object+0x44/0x1f8
[21630.927153]  __create_object+0x34/0xc8
[21630.927604]  kmemleak_alloc+0xb8/0xd8
[21630.928052]  kmem_cache_alloc_noprof+0x368/0x5c8
[21630.928606]  getname_flags.part.0+0xa4/0x610
[21630.929112]  getname_flags+0x80/0xd8
[21630.929557]  vfs_fstatat+0xc8/0xe0
[21630.929975]  __do_sys_newfstatat+0xa0/0x100
[21630.930469]  __arm64_sys_newfstatat+0x90/0xd8
[21630.931046]  invoke_syscall+0xd4/0x258
[21630.931685]  el0_svc_common.constprop.0+0xb4/0x240
[21630.932467]  do_el0_svc+0x48/0x68
[21630.932972]  el0_svc+0x40/0xe0
[21630.933472]  el0t_64_sync_handler+0xa0/0xe8
[21630.934151]  el0t_64_sync+0x1ac/0x1b0
[21630.934923] Code: aa1803e0 97ffef2b a9446bf9 17ffff9c (d4210000)
[21630.936461] SMP: stopping secondary CPUs
[21630.939550] Starting crashdump kernel...
[21630.940108] Bye!

Quoted 32 lines

Fixes 09c46563ff6d ("codetag: debug: introduce OBJEXTS_ALLOC_FAIL to mark failed slab_ext allocations")

Signed-off-by Hao Ge <[email protected]>

---
   mm/slub.c | 12 +++++++++++-
   1 file changed, 11 insertions(+), 1 deletion(-)

mm/slub.c +11 -2

index d4367f25b20d..cda8f75b72e7 100644
@@ -2046,7 +2046,17 @@ static inline void mark_objexts_empty(struct slabobj_ext *obj_exts)
          if (slab_exts) {
                  unsigned int offs = obj_to_index(obj_exts_slab->slab_cache,
                                                   obj_exts_slab, obj_exts);
-               /* codetag should be NULL */
+
+               /*
+                * codetag should be either NULL or CODETAG_EMPTY.
+                * When the same slab calls handle_failed_objexts_alloc,
+                * it will set us to CODETAG_EMPTY.
+                *
+                * If codetag is already CODETAG_EMPTY, no action is needed here.
+                */
+               if (unlikely(is_codetag_empty(&slab_exts[offs].ref)))
+                       return;
+
                  WARN_ON(slab_exts[offs].ref.ct);
                  set_codetag_empty(&slab_exts[offs].ref);
          }
--

2.25.1

Suren Baghdasaryan

2025-10-28 22:52 UTC #5 lore raw

Quoted 62 lines · Hao Ge

HI Suren
Quoted 47 lines · Suren Baghdasaryan
Quoted 28 lines · Hao Ge
Hi Suren
Quoted 12 lines · Suren Baghdasaryan
Quoted 11 lines · Hao Ge
From: Hao Ge <[email protected]>
Even though obj_exts was created with the __GFP_NO_OBJ_EXT flag, objects in the same slab may have their extensions allocated via alloc_slab_obj_exts, and handle_failed_objexts_alloc may be called within alloc_slab_obj_exts to set their codetag to CODETAG_EMPTY.
Therefore, both NULL and CODETAG_EMPTY are valid for the codetag of slabobj_ext, as we do not need to re-set it to CODETAG_EMPTY if it is already CODETAG_EMPTY. It also resolves the warning triggered when the codetag is CODETAG_EMPTY during slab freeing.
Quoted 8 lines
I'm not sure what scenario leads to handle_failed_objexts_alloc() and mark_objexts_empty() being used against the same codetag reference. Could you please explain the exact scenario you hit?
handle_failed_objexts_alloc() assigns CODETAG_EMPTY to the elements of the obj_exts vector while mark_objexts_empty() assigns CODETAG_EMPTY to the obj_ext of the obj_exts vector itself. In what case do these two calls operate on the same reference?
This issue also occurred during our memory stress testing.
I apologize for the incorrect description in my commit message:
Quoted 7 lines
The possibility of its occurrence should be as follows:
When a slab allocates a slabobj_ext, the slab to which this slabobj_ext belongs may have already allocated its own slabobj_ext
and called handle_failed_objexts_alloc. That is to say, the codetag of this slabobj_ext has been set to CODETAG_EMPTY.
Ah, ok. Let's see if I understood this correctly. The slab from which slabobj_ext objects are allocated (let's call it slabA) tries to allocate its own slabobj_ext, fails, then succeeds and calls handle_failed_objexts_alloc() which sets all elements of its slabA->obj_exts[] to CODETAG_EMPTY. Then slabobj_ext object is allocated from slabA with __GFP_NO_OBJ_EXT, therefore it leaves slabA->obj_exts[obj_idx] intact and equal to CODETAG_EMPTY instead of NULL. At this point, slabB->obj_exts points to an object in slabA. When slabB is freed and free_slab_obj_exts() gets called to free slabB->obj_exts, it detects that slabA->obj_exts[obj_idx] is not NULL and generates this warning. In your callstack stack the freeing seems
Quoted 8 lines
to happen inside kmem_cache_alloc_noprof() and I think that's because we lost the race and freeing the vector we allocated here:
https://elixir.bootlin.com/linux/v6.18-rc3/source/mm/slub.c#L2165 but the scenario is pretty much the same as if we didn't lose the race. The warning would happen later on I think, when we would be freeing slabB->obj_exts. The key for reproducing this is to fail allocation for a slab that is used to allocate slabobj_ext objects. Is my understanding correct?

Quoted 1 line

Yes, your explanation is extremely detailed and thorough.

Ok, let's work on the changelog them. How about something like this:

```
When alloc_slab_obj_exts() fails and then later succeeds in allocating
a slab extension vector, it calls handle_failed_objexts_alloc() to
mark all objects in the vector as empty. As a result all objects in
this slab (slabA) will have their extensions set to CODETAG_EMPTY.
Later on if this slabA is used to allocate a slabobj_ext vector for
another slab (slabB), we end up with the slabB->obj_exts pointing to a
slabobj_ext vector that itself has a non-NULL slabobj_ext equal to
CODETAG_EMPTY. When slabB gets freed, free_slab_obj_exts() is called
to free slabB->obj_exts vector. free_slab_obj_exts() calls
mark_objexts_empty(slabB->obj_exts) which will generate a warning
because it expects slabobj_ext vectors to have a NULL obj_ext, not
CODETAG_EMPTY.

Modify mark_objexts_empty() to skip the warning and setting the
obj_ext value if it's already set to CODETAG_EMPTY.
```

I know it's still hard to read but I could not come up with a better one :/

Quoted 104 lines

BTW, your fix seems fine to me, I just want to understand the scenario so that we can explain it correctly.

Quoted 99 lines

To quickly detect this WARN, I modified the code from:WARN_ON(slab_exts[offs].ref.ct) to WARN_ON(slab_exts[offs].ref.ct == 1);

We then obtained this message:

[21630.898561] ------------[ cut here ]------------
[21630.898596] kernel BUG at mm/slub.c:2050!
[21630.898611] Internal error: Oops - BUG: 00000000f2000800 [#1] SMP
[21630.900372] Modules linked in: squashfs isofs vfio_iommu_type1

[21630.909177] CPU: 3 UID: 0 PID: 3787 Comm: kylin-process-m Kdump:
loaded Tainted: G        W           6.18.0-rc1+ #74 PREEMPT(voluntary)
[21630.910495] Tainted: [W]=WARN
[21630.910867] Hardware name: QEMU KVM Virtual Machine, BIOS unknown
2/2/2022
[21630.911625] pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS
BTYPE=--)
[21630.912392] pc : __free_slab+0x228/0x250
[21630.912868] lr : __free_slab+0x18c/0x250[21630.913334] sp :
ffff8000a02f73e0
[21630.913830] x29: ffff8000a02f73e0 x28: fffffdffc43fc800 x27:
ffff0000c0011c40
[21630.914677] x26: ffff0000c000cac0 x25: ffff00010fe5e5f0 x24:
ffff000102199b40
[21630.915469] x23: 0000000000000003 x22: 0000000000000003 x21:
ffff0000c0011c40
[21630.916259] x20: fffffdffc4086600 x19: fffffdffc43fc800 x18:
0000000000000000
[21630.917048] x17: 0000000000000000 x16: 0000000000000000 x15:
0000000000000000
[21630.917837] x14: 0000000000000000 x13: 0000000000000000 x12:
ffff70001405ee66
[21630.918640] x11: 1ffff0001405ee65 x10: ffff70001405ee65 x9 :
ffff800080a295dc
[21630.919442] x8 : ffff8000a02f7330 x7 : 0000000000000000 x6 :
0000000000003000
[21630.920232] x5 : 0000000024924925 x4 : 0000000000000001 x3 :
0000000000000007
[21630.921021] x2 : 0000000000001b40 x1 : 000000000000001f x0 :
0000000000000001
[21630.921810] Call trace:
[21630.922130]  __free_slab+0x228/0x250 (P)
[21630.922669]  free_slab+0x38/0x118
[21630.923079]  free_to_partial_list+0x1d4/0x340
[21630.923591]  __slab_free+0x24c/0x348
[21630.924024]  ___cache_free+0xf0/0x110
[21630.924468]  qlist_free_all+0x78/0x130
[21630.924922]  kasan_quarantine_reduce+0x114/0x148
[21630.925525]  __kasan_slab_alloc+0x7c/0xb0
[21630.926006]  kmem_cache_alloc_noprof+0x164/0x5c8
[21630.926699]  __alloc_object+0x44/0x1f8
[21630.927153]  __create_object+0x34/0xc8
[21630.927604]  kmemleak_alloc+0xb8/0xd8
[21630.928052]  kmem_cache_alloc_noprof+0x368/0x5c8
[21630.928606]  getname_flags.part.0+0xa4/0x610
[21630.929112]  getname_flags+0x80/0xd8
[21630.929557]  vfs_fstatat+0xc8/0xe0
[21630.929975]  __do_sys_newfstatat+0xa0/0x100
[21630.930469]  __arm64_sys_newfstatat+0x90/0xd8
[21630.931046]  invoke_syscall+0xd4/0x258
[21630.931685]  el0_svc_common.constprop.0+0xb4/0x240
[21630.932467]  do_el0_svc+0x48/0x68
[21630.932972]  el0_svc+0x40/0xe0
[21630.933472]  el0t_64_sync_handler+0xa0/0xe8
[21630.934151]  el0t_64_sync+0x1ac/0x1b0
[21630.934923] Code: aa1803e0 97ffef2b a9446bf9 17ffff9c (d4210000)
[21630.936461] SMP: stopping secondary CPUs
[21630.939550] Starting crashdump kernel...
[21630.940108] Bye!

Quoted 15 lines

Fixes 09c46563ff6d ("codetag: debug: introduce OBJEXTS_ALLOC_FAIL to mark failed slab_ext allocations")

Signed-off-by Hao Ge <[email protected]>

---
   mm/slub.c | 12 +++++++++++-
   1 file changed, 11 insertions(+), 1 deletion(-)

mm/slub.c +0 -1

index d4367f25b20d..cda8f75b72e7 100644
@@ -2046,7 +2046,17 @@ static inline void mark_objexts_empty(struct slabobj_ext *obj_exts)
          if (slab_exts) {
                  unsigned int offs = obj_to_index(obj_exts_slab->slab_cache,
                                                   obj_exts_slab, obj_exts);
-               /* codetag should be NULL */

Quoted 8 lines

mm/slub.c static inline void mark_objexts_empty(struct slabobj_ext *obj_exts) · line 2056

Quoted 8 lines

mm/slub.c +8 -0

+
+               /*
+                * codetag should be either NULL or CODETAG_EMPTY.
+                * When the same slab calls handle_failed_objexts_alloc,
+                * it will set us to CODETAG_EMPTY.
+                *
+                * If codetag is already CODETAG_EMPTY, no action is needed here.
+                */

This comment is more confusing than helpful IMO. I would leave the current comment intact and just add this check before it like this:

+ if (unlikely(is_codetag_empty(&slab_exts[offs].ref)))
+ return;
+

                /* codetag should be NULL */
                WARN_ON(slab_exts[offs].ref.ct);
                ...

Quoted 9 lines

mm/slub.c +3 -1

+               if (unlikely(is_codetag_empty(&slab_exts[offs].ref)))
+                       return;
+
                  WARN_ON(slab_exts[offs].ref.ct);
                  set_codetag_empty(&slab_exts[offs].ref);
          }
--

2.25.1