Re: [PATCH v2 02/16] mm/slab: do not init any kfence objects on allocation

[Suren Baghdasaryan]

On Thu, Jun 11, 2026 at 9:37 AM Vlastimil Babka (SUSE)
<vbabka@xxxxxxxxxx> wrote:
>
> On 6/11/26 17:11, Harry Yoo wrote:
> >
> >> From 3a1c4398ce9f361a4e6f4d9946eab6237eea89c2 Mon Sep 17 00:00:00 2001
> >> From: "Vlastimil Babka (SUSE)" <vbabka@xxxxxxxxxx>
> >> Date: Wed, 10 Jun 2026 17:40:04 +0200
> >> Subject: [PATCH] mm/slab: do not init any kfence objects on allocation
> >>
> >> When init (zeroing) on allocation is requested, for kmalloc() we
> >> generally have to zero the full object size even if a smaller size is
> >> requested, in order to provide krealloc()'s __GFP_ZERO guarantees.
> >>
> >> When we end up allocating a kfence object, kfence perfoms the zeroing on
> >
> > nit: perfoms -> performs
>
> Fixed.
>
> >> its own because has its own redzone beyond the requested size. Thus

nit: s/because has/because it has

> >> slab_post_alloc_hook() has an 'init' parameter which has to be evaluated
> >> in all callers (via slab_want_init_on_alloc()) and should be false for
> >> kfence allocations.
> >>
> >> For kfence allocations in slab_alloc_node() this is achieved by subtly
> >> skipping over the slab_want_init_on_alloc() call. Other callers (i.e.
> >> kmem_cache_alloc_bulk_noprof()) however evaluate it unconditionally even
> >> if they do end up with a kfence allocation. This is only subtly not a
> >> problem, as those are not kmalloc allocations and thus the "requested
> >> size" equals s->object_size and thus it cannot interfere with kfence's
> >> redzone. There's just a unnecessary double zeroing (in both kfence and
> >> slab_post_alloc_hook()), but it's all very fragile and contradicts the
> >> comment in kfence_guarded_alloc().
> >>
> >> Remove this subtlety and simplify the code by eliminating the init
> >> parameter from slab_post_alloc_hook() and make it call
> >> slab_want_init_on_alloc() itself. Instead add a is_kfence_address()
> >> check before performing the memset, which will start doing the right
> >> thing for all callers of slab_post_alloc_hook().
> >>
> >> This potentially adds overhead of the is_kfence_address() check to
> >> allocation hotpath, but that one is designed to be as small as possible,
> >> and it's only evaluated if zeroing is about to happen. This means (aside
> >> from init_on_alloc hardening) only for __GFP_ZERO allocations, and the
> >> zeroing itself comes with an overhead likely larger than the added
> >> check.
> >
> >> While at it, refactor the handling of evaluating when KASAN does the
> >> init instead of SLUB, with no intended functional changes. A
> >> non-functional change is that we don't pass kasan_init as true to
> >> kasan_slab_alloc() if kasan has no integrated init, but then the value
> >> is ignored anyway, so it's theoretically more correct.
> >
> > Right.
> >
> >> Thanks to Harry Yoo for the initial refactoring attempt, and for updated
> >> comments that are used here.
> >
> > No problem ;)
> >
> >> Link: https://patch.msgid.link/20260610-slab_alloc_flags-v2-2-7190909db118@xxxxxxxxxx
> >> Signed-off-by: Vlastimil Babka (SUSE) <vbabka@xxxxxxxxxx>
> >> ---
> >
> > Looks good to me,
> > Reviewed-by: Harry Yoo (Oracle) <harry@xxxxxxxxxx>

Reviewed-by: Suren Baghdasaryan <surenb@xxxxxxxxxx>

>
> Thanks!
>
> > Thanks!
> >
>