From nobody Sat Feb 7 22:07:21 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 6F364313550 for ; Sat, 7 Feb 2026 13:27:08 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770470828; cv=none; b=qhlplajz+RQzz5gEFhdiwxV07wqScKAc83DlvZUI62LFsKdV10V70UpQQvrPDzRQ1WcwmgVrJyLGnqmI4FFUlhmGLHhqP045XalKJdCoPCHRAD2bBFmRRiH2UTW8VvtEfl2TItr67aeDvIXODsjEe4d3TN79lRwJhQPsLcN1O3o= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770470828; c=relaxed/simple; bh=IuThHW4eab/OvQ+Vsiwnms5Gs/dxg92edhe+M0wtpcc=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:Content-Type; b=dljnW0V1+xZVFOm8zBzP+GOiHyhZbgh9p1K2GvzrVHx207XpudIfGTp5mrAmiJ4UmelTNT79DqZaHDmYlqdKOPfQ4e3JJL+amTggF08aoyaGfP/D4cIiGCBUzO3Dboijk4QJ8WcZo4G0px/GGkNMktrQVbLtoHu28c9D4AMhD3U= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=V7F8l42k; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="V7F8l42k" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 8EA1DC116D0; Sat, 7 Feb 2026 13:27:07 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1770470828; bh=IuThHW4eab/OvQ+Vsiwnms5Gs/dxg92edhe+M0wtpcc=; h=From:To:Cc:Subject:Date:From; b=V7F8l42koeAmHSd3BKKtUaEibtysWWIdU4hrMrQCDaPDfFUibO8hewyVMtDIyAqgB yIWUgBlj7X+yKK0ngryFdv0nSiBcsN/LM9MkW6VPVomUHu6aoZLjFpHsDAO7F14Lo2 581JNpXSD4inIY5kB4vGhK00qACUO7bcGq2VtLNmLr6zMJMhSPv6jvwxv2Weba0ePH cYqME+z+dpyj+OTUuprQHMdoXrF3qZq7PQSNgXbdjtYgcqRlG3OiTPhaPhz7SlY38E wfCd2qhlpaVQ+APf9AEqJsm2iUF3f9g66iNU+Vv3CqaSt0creCy9rhEHZvWge7EZ3e zZJtmAXHdXGjA== From: Thomas Gleixner To: LKML Cc: Vlastimil Babka , Peter Zijlstra , Alexei Starovoitov , linux-mm@vger.kernel.org Subject: debugobject: Make it work with deferred page initialization - again Date: Sat, 07 Feb 2026 14:27:05 +0100 Message-ID: <87pl6gznti.ffs@tglx> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" debugobjects uses __GFP_HIGH for allocations as it might be invoked within locked regions. That worked perfectly fine until v6.18. It still works correctly when deferred page initialization is disabled and works by chance when no page allocation is required before deferred page initialization has completed. Since v6.18 allocations w/o a reclaim flag cause new_slab() to end up in alloc_frozen_pages_nolock_noprof(), which returns early when deferred page initialization has not yet completed. As the deferred page initialization takes quite a while the debugobject pool is depleted and debugobjects are disabled. This can be worked around when PREEMPT_COUNT is enabled as that allows debugobjects to add __GFP_KSWAPD_RECLAIM to the GFP flags when the context is preemtible. When PREEMPT_COUNT is disabled the context is unknown and the reclaim bit can't be set because the caller might hold locks which might deadlock in the allocator. In preemptible context the reclaim bit is harmless and not a performance issue as that's usually invoked from slow path initialization context. That makes debugobjects depend on PREEMPT_COUNT || !DEFERRED_STRUCT_PAGE_IN= IT. Fixes: af92793e52c3 ("slab: Introduce kmalloc_nolock() and kfree_nolock().") Signed-off-by: Thomas Gleixner Acked-by: Alexei Starovoitov --- lib/Kconfig.debug | 1 + lib/debugobjects.c | 19 ++++++++++++++++++- 2 files changed, 19 insertions(+), 1 deletion(-) --- a/lib/Kconfig.debug +++ b/lib/Kconfig.debug @@ -753,6 +753,7 @@ source "mm/Kconfig.debug" =20 config DEBUG_OBJECTS bool "Debug object operations" + depends on PREEMPT_COUNT || !DEFERRED_STRUCT_PAGE_INIT depends on DEBUG_KERNEL help If you say Y here, additional code will be inserted into the --- a/lib/debugobjects.c +++ b/lib/debugobjects.c @@ -398,9 +398,26 @@ static void fill_pool(void) =20 atomic_inc(&cpus_allocating); while (pool_should_refill(&pool_global)) { + gfp_t gfp =3D __GFP_HIGH | __GFP_NOWARN; HLIST_HEAD(head); =20 - if (!kmem_alloc_batch(&head, obj_cache, __GFP_HIGH | __GFP_NOWARN)) + /* + * Allow reclaim only in preemptible context and during + * early boot. If not preemptible, the caller might hold + * locks causing a deadlock in the allocator. + * + * If the reclaim flag is not set during early boot then + * allocations, which happen before deferred page + * initialization has completed, will fail. + * + * In preemptible context the flag is harmless and not a + * performance issue as that's usually invoked from slow + * path initialization context. + */ + if (preemptible() || system_state < SYSTEM_SCHEDULING) + gfp |=3D __GFP_KSWAPD_RECLAIM; + + if (!kmem_alloc_batch(&head, obj_cache, gfp)) break; =20 guard(raw_spinlock_irqsave)(&pool_lock);