linux-kernel - Re: [PATCH] codetag: debug: Handle existing CODETAG_EMPTY in mark_objexts_empty for slabobj

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAJuCfpF+0ok85A1ZhbptSzrB-X6CUj=TMj9ZvwzjV1tO5PqFbA@mail.gmail.com>
Date: Mon, 27 Oct 2025 12:44:44 -0700
From: Suren Baghdasaryan <surenb@...gle.com>
To: Hao Ge <hao.ge@...ux.dev>
Cc: Vlastimil Babka <vbabka@...e.cz>, Andrew Morton <akpm@...ux-foundation.org>, 
	Christoph Lameter <cl@...two.org>, David Rientjes <rientjes@...gle.com>, 
	Roman Gushchin <roman.gushchin@...ux.dev>, Harry Yoo <harry.yoo@...cle.com>, 
	Shakeel Butt <shakeel.butt@...ux.dev>, linux-mm@...ck.org, linux-kernel@...r.kernel.org, 
	Hao Ge <gehao@...inos.cn>
Subject: Re: [PATCH] codetag: debug: Handle existing CODETAG_EMPTY in
 mark_objexts_empty for slabobj_ext

On Mon, Oct 27, 2025 at 1:53 AM Hao Ge <hao.ge@...ux.dev> wrote:
>
> From: Hao Ge <gehao@...inos.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@...inos.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
>