Re: [PATCH v2 06/16] mm/slab: add alloc_flags to slab_alloc_context

[Suren Baghdasaryan]

On Thu, Jun 11, 2026 at 8:51 PM Hao Li <hao.li@xxxxxxxxx> wrote:
>
> On Wed, Jun 10, 2026 at 05:40:08PM +0200, Vlastimil Babka (SUSE) wrote:
> > Add alloc_flags as a new field to the slab_alloc_context helper struct,
> > so we can pass it to more functions in the slab implementation without
> > adding another function parameter.
> >
> > Start checking them via alloc_flags_allow_spinning() in
> > alloc_single_from_new_slab() (where we can drop the allow_spin
> > parameter) and ___slab_alloc(). This further reduces false-positive
> > spinning-not-allowed from allocations that are not kmalloc_nolock() but
> > lack __GFP_RECLAIM flags.

___slab_alloc() is now using alloc_flags_allow_spinning(alloc_flags)
while function it uses (get_from_partial()->get_from_any_partial()) is
still using gfpflags_allow_spinning(gfpflags). I'm guessing
get_from_any_partial() will be converted later on but I wonder if that
conversion would better be done in the same patch to avoid
inconsistent behavior during possible bisection.

> >
> > _kmalloc_nolock_noprof() initializes ac.alloc_flags using its flags that
> > are SLAB_ALLOC_TRYLOCK. slab_alloc_node() and __kmem_cache_alloc_bulk()
> > are not reachable from kmalloc_nolock() and all their callers expect
> > spinning to be allowed, so they can use SLAB_ALLOC_DEFAULT. This is
> > temporary as the scope of slab_alloc_context will further move to the
> > callers, making the alloc_flags usage more obvious.
> >
> > Signed-off-by: Vlastimil Babka (SUSE) <vbabka@xxxxxxxxxx>
> > ---
>
> Reviewed-by: Hao Li <hao.li@xxxxxxxxx>
>
> --
> Thanks,
> Hao