Commit c379b745 authored by Vlastimil Babka's avatar Vlastimil Babka
Browse files

slab: prevent infinite loop in kmalloc_nolock() with debugging 



In review of a followup work, Harry noticed a potential infinite loop.
Upon closed inspection, it already exists for kmalloc_nolock() on a
cache with debugging enabled, since commit af92793e ("slab:
Introduce kmalloc_nolock() and kfree_nolock().")

When alloc_single_from_new_slab() fails to trylock node list_lock, we
keep retrying to get partial slab or allocate a new slab. If we indeed
interrupted somebody holding the list_lock, the trylock fill fail
deterministically and we end up allocating and defer-freeing slabs
indefinitely with no progress.

To fix it, fail the allocation if spinning is not allowed. This is
acceptable in the restricted context of kmalloc_nolock(), especially
with debugging enabled.

Reported-by: default avatarHarry Yoo <harry.yoo@oracle.com>
Closes: https://lore.kernel.org/all/aQLqZjjq1SPD3Fml@hyeyoo/


Fixes: af92793e ("slab: Introduce kmalloc_nolock() and kfree_nolock().")
Acked-by: default avatarAlexei Starovoitov <ast@kernel.org>
Reviewed-by: default avatarHarry Yoo <harry.yoo@oracle.com>
Link: https://patch.msgid.link/20251103-fix-nolock-loop-v1-1-6e2b3e82b9da@suse.cz


Signed-off-by: default avatarVlastimil Babka <vbabka@suse.cz>
parent 7f434e1d

mm/slub.c

+5 −1
Original line number Diff line number Diff line
@@ -4666,8 +4666,12 @@ static void *___slab_alloc(struct kmem_cache *s, gfp_t gfpflags, int node, 
	if (kmem_cache_debug(s)) {

		freelist = alloc_single_from_new_slab(s, slab, orig_size, gfpflags);



		if (unlikely(!freelist))

		if (unlikely(!freelist)) {

			/* This could cause an endless loop. Fail instead. */

			if (!allow_spin)

				return NULL;

			goto new_objects;

		}



		if (s->flags & SLAB_STORE_USER)

			set_track(s, freelist, TRACK_ALLOC, addr,