* [PATCH] codetag: debug: Handle existing CODETAG_EMPTY in mark_objexts_empty for slabobj_ext
@ 2025-10-27 8:52 Hao Ge
2025-10-27 19:44 ` Suren Baghdasaryan
0 siblings, 1 reply; 6+ messages in thread
From: Hao Ge @ 2025-10-27 8:52 UTC (permalink / raw)
To: Vlastimil Babka, Andrew Morton, Christoph Lameter, David Rientjes,
Roman Gushchin, Harry Yoo, Suren Baghdasaryan
Cc: Shakeel Butt, linux-mm, linux-kernel, Hao Ge
From: Hao Ge <gehao@kylinos.cn>
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 <gehao@kylinos.cn>
---
mm/slub.c | 12 +++++++++++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/mm/slub.c b/mm/slub.c
index d4367f25b20d..cda8f75b72e7 100644
--- a/mm/slub.c
+++ b/mm/slub.c
@@ -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
^ permalink raw reply related [flat|nested] 6+ messages in thread
* Re: [PATCH] codetag: debug: Handle existing CODETAG_EMPTY in mark_objexts_empty for slabobj_ext
2025-10-27 8:52 [PATCH] codetag: debug: Handle existing CODETAG_EMPTY in mark_objexts_empty for slabobj_ext Hao Ge
@ 2025-10-27 19:44 ` Suren Baghdasaryan
2025-10-28 1:30 ` Hao Ge
0 siblings, 1 reply; 6+ messages in thread
From: Suren Baghdasaryan @ 2025-10-27 19:44 UTC (permalink / raw)
To: Hao Ge
Cc: Vlastimil Babka, Andrew Morton, Christoph Lameter, David Rientjes,
Roman Gushchin, Harry Yoo, Shakeel Butt, linux-mm, linux-kernel,
Hao Ge
On Mon, Oct 27, 2025 at 1:53 AM Hao Ge <hao.ge@linux.dev> wrote:
>
> From: Hao Ge <gehao@kylinos.cn>
>
> 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.
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?
>
> Fixes: 09c46563ff6d ("codetag: debug: introduce OBJEXTS_ALLOC_FAIL to mark failed slab_ext allocations")
> Signed-off-by: Hao Ge <gehao@kylinos.cn>
> ---
> mm/slub.c | 12 +++++++++++-
> 1 file changed, 11 insertions(+), 1 deletion(-)
>
> diff --git a/mm/slub.c b/mm/slub.c
> index d4367f25b20d..cda8f75b72e7 100644
> --- a/mm/slub.c
> +++ b/mm/slub.c
> @@ -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
>
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] codetag: debug: Handle existing CODETAG_EMPTY in mark_objexts_empty for slabobj_ext
2025-10-27 19:44 ` Suren Baghdasaryan
@ 2025-10-28 1:30 ` Hao Ge
2025-10-28 16:19 ` Suren Baghdasaryan
0 siblings, 1 reply; 6+ messages in thread
From: Hao Ge @ 2025-10-28 1:30 UTC (permalink / raw)
To: Suren Baghdasaryan
Cc: Vlastimil Babka, Andrew Morton, Christoph Lameter, David Rientjes,
Roman Gushchin, Harry Yoo, Shakeel Butt, linux-mm, linux-kernel,
Hao Ge
Hi Suren
On 2025/10/28 03:44, Suren Baghdasaryan wrote:
> On Mon, Oct 27, 2025 at 1:53 AM Hao Ge <hao.ge@linux.dev> wrote:
>> From: Hao Ge <gehao@kylinos.cn>
>>
>> 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.
> 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!
>> Fixes: 09c46563ff6d ("codetag: debug: introduce OBJEXTS_ALLOC_FAIL to mark failed slab_ext allocations")
>> Signed-off-by: Hao Ge <gehao@kylinos.cn>
>> ---
>> mm/slub.c | 12 +++++++++++-
>> 1 file changed, 11 insertions(+), 1 deletion(-)
>>
>> diff --git a/mm/slub.c b/mm/slub.c
>> index d4367f25b20d..cda8f75b72e7 100644
>> --- a/mm/slub.c
>> +++ b/mm/slub.c
>> @@ -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
>>
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] codetag: debug: Handle existing CODETAG_EMPTY in mark_objexts_empty for slabobj_ext
2025-10-28 1:30 ` Hao Ge
@ 2025-10-28 16:19 ` Suren Baghdasaryan
2025-10-28 16:57 ` Hao Ge
0 siblings, 1 reply; 6+ messages in thread
From: Suren Baghdasaryan @ 2025-10-28 16:19 UTC (permalink / raw)
To: Hao Ge
Cc: Vlastimil Babka, Andrew Morton, Christoph Lameter, David Rientjes,
Roman Gushchin, Harry Yoo, Shakeel Butt, linux-mm, linux-kernel,
Hao Ge
On Mon, Oct 27, 2025 at 6:31 PM Hao Ge <hao.ge@linux.dev> wrote:
>
> Hi Suren
>
>
> On 2025/10/28 03:44, Suren Baghdasaryan wrote:
> > On Mon, Oct 27, 2025 at 1:53 AM Hao Ge <hao.ge@linux.dev> wrote:
> >> From: Hao Ge <gehao@kylinos.cn>
> >>
> >> 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.
> > 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.
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.
>
> 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!
>
> >> Fixes: 09c46563ff6d ("codetag: debug: introduce OBJEXTS_ALLOC_FAIL to mark failed slab_ext allocations")
> >> Signed-off-by: Hao Ge <gehao@kylinos.cn>
> >> ---
> >> mm/slub.c | 12 +++++++++++-
> >> 1 file changed, 11 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/mm/slub.c b/mm/slub.c
> >> index d4367f25b20d..cda8f75b72e7 100644
> >> --- a/mm/slub.c
> >> +++ b/mm/slub.c
> >> @@ -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
> >>
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] codetag: debug: Handle existing CODETAG_EMPTY in mark_objexts_empty for slabobj_ext
2025-10-28 16:19 ` Suren Baghdasaryan
@ 2025-10-28 16:57 ` Hao Ge
2025-10-28 22:52 ` Suren Baghdasaryan
0 siblings, 1 reply; 6+ messages in thread
From: Hao Ge @ 2025-10-28 16:57 UTC (permalink / raw)
To: Suren Baghdasaryan
Cc: Vlastimil Babka, Andrew Morton, Christoph Lameter, David Rientjes,
Roman Gushchin, Harry Yoo, Shakeel Butt, linux-mm, linux-kernel,
Hao Ge
HI Suren
On 2025/10/29 00:19, Suren Baghdasaryan wrote:
> On Mon, Oct 27, 2025 at 6:31 PM Hao Ge <hao.ge@linux.dev> wrote:
>> Hi Suren
>>
>>
>> On 2025/10/28 03:44, Suren Baghdasaryan wrote:
>>> On Mon, Oct 27, 2025 at 1:53 AM Hao Ge <hao.ge@linux.dev> wrote:
>>>> From: Hao Ge <gehao@kylinos.cn>
>>>>
>>>> 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.
>>> 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.
> 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?
Yes, your explanation is extremely detailed and thorough.
> BTW, your fix seems fine to me, I just want to understand the scenario
> so that we can explain it correctly.
>
>> 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!
>>
>>>> Fixes: 09c46563ff6d ("codetag: debug: introduce OBJEXTS_ALLOC_FAIL to mark failed slab_ext allocations")
>>>> Signed-off-by: Hao Ge <gehao@kylinos.cn>
>>>> ---
>>>> mm/slub.c | 12 +++++++++++-
>>>> 1 file changed, 11 insertions(+), 1 deletion(-)
>>>>
>>>> diff --git a/mm/slub.c b/mm/slub.c
>>>> index d4367f25b20d..cda8f75b72e7 100644
>>>> --- a/mm/slub.c
>>>> +++ b/mm/slub.c
>>>> @@ -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
>>>>
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] codetag: debug: Handle existing CODETAG_EMPTY in mark_objexts_empty for slabobj_ext
2025-10-28 16:57 ` Hao Ge
@ 2025-10-28 22:52 ` Suren Baghdasaryan
0 siblings, 0 replies; 6+ messages in thread
From: Suren Baghdasaryan @ 2025-10-28 22:52 UTC (permalink / raw)
To: Hao Ge
Cc: Vlastimil Babka, Andrew Morton, Christoph Lameter, David Rientjes,
Roman Gushchin, Harry Yoo, Shakeel Butt, linux-mm, linux-kernel,
Hao Ge
On Tue, Oct 28, 2025 at 9:58 AM Hao Ge <hao.ge@linux.dev> wrote:
>
> HI Suren
>
>
> On 2025/10/29 00:19, Suren Baghdasaryan wrote:
> > On Mon, Oct 27, 2025 at 6:31 PM Hao Ge <hao.ge@linux.dev> wrote:
> >> Hi Suren
> >>
> >>
> >> On 2025/10/28 03:44, Suren Baghdasaryan wrote:
> >>> On Mon, Oct 27, 2025 at 1:53 AM Hao Ge <hao.ge@linux.dev> wrote:
> >>>> From: Hao Ge <gehao@kylinos.cn>
> >>>>
> >>>> 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.
> >>> 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.
> > 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?
>
>
> 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 :/
>
>
> > BTW, your fix seems fine to me, I just want to understand the scenario
> > so that we can explain it correctly.
> >
> >> 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!
> >>
> >>>> Fixes: 09c46563ff6d ("codetag: debug: introduce OBJEXTS_ALLOC_FAIL to mark failed slab_ext allocations")
> >>>> Signed-off-by: Hao Ge <gehao@kylinos.cn>
> >>>> ---
> >>>> mm/slub.c | 12 +++++++++++-
> >>>> 1 file changed, 11 insertions(+), 1 deletion(-)
> >>>>
> >>>> diff --git a/mm/slub.c b/mm/slub.c
> >>>> index d4367f25b20d..cda8f75b72e7 100644
> >>>> --- a/mm/slub.c
> >>>> +++ b/mm/slub.c
> >>>> @@ -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.
> >>>> + */
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);
...
> >>>> + 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
> >>>>
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2025-10-28 22:53 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2025-10-27 8:52 [PATCH] codetag: debug: Handle existing CODETAG_EMPTY in mark_objexts_empty for slabobj_ext Hao Ge
2025-10-27 19:44 ` Suren Baghdasaryan
2025-10-28 1:30 ` Hao Ge
2025-10-28 16:19 ` Suren Baghdasaryan
2025-10-28 16:57 ` Hao Ge
2025-10-28 22:52 ` Suren Baghdasaryan
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).