From nobody Thu Apr 16 08:32:23 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 A031D31280C for ; Sun, 1 Mar 2026 16:40:33 +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=1772383233; cv=none; b=NWq8jiW5ntLTz+gs17FZRgU23HvVvY/vNgTWMBKThoslzD2y9jV8r9QiTOytI4fXsAk1p9JVU7NIE5GC2/CMui4KkuL3tG9SVRFFGRWU9L5BfYwupNGaM3B2uIU2F/60F5T1vfaUVVJdqmC0JUP1VHy8d+7sA2uCGh7rn4AwMRw= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772383233; c=relaxed/simple; bh=o6zSV28SBvH1HjzsSczoCaNOwhi5PromKzHzu/iIHtg=; h=Date:From:To:Cc:Subject:Message-ID:Content-Type:MIME-Version; b=eoB7nSAjZhVAcEosbIZYjCtxDAZK+H8bb3NiwlsO150poP8PZVYd4UiSvRVKjXcMjAODgNXpHrPtTStAm4xWjCJ3z6v1Z0/QW0V5WTcolvkGH5BNxTxSiqtZD/fsnS8E6quustmMteMMl/b+KuFywPnR3qaKXKa+15T9tMA/xK4= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=ABMVh006; 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="ABMVh006" Received: by smtp.kernel.org (Postfix) with ESMTPSA id A7BA1C19422; Sun, 1 Mar 2026 16:40:32 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772383233; bh=o6zSV28SBvH1HjzsSczoCaNOwhi5PromKzHzu/iIHtg=; h=Date:From:To:Cc:Subject:From; b=ABMVh006Om8PSHz8ZAnGEp4OdjeT5qtCf73m5hU/E9P88ZnG6UOY/qd2wY2x2VbI4 F4Zl2ZKUxhA5jEv6OEkZT7pDMVRtD1+WXfTa/LWmQtvXmYJgh4iPJi76gmMS/76cwb xtQjrN1LX2g+EAl8VlL0mpvZ0Nr1P+v+DUVrtLFnC01370q1D5Nb+nWuIKJE4oKjQz G8noKkzvdga1qRHPnM2/ELkjQ7vvLDdgst2ji81GJfAUHx7Uwysz7P7hJ7v6KuwRFP 6aFD/hfePrc4QYTeJuFAPJa/ihLNk9D0aDEJbliDvafmTPx2ZzsvvtA0MXOmytSWb7 hyJqe+zHmROBQ== Date: Sun, 01 Mar 2026 17:40:29 +0100 From: Thomas Gleixner To: Linus Torvalds Cc: linux-kernel@vger.kernel.org, x86@kernel.org Subject: [GIT pull] core/debugobjects for v7.0-rc2 Message-ID: <177238319386.198864.17533620995806468113.tglx@xen13> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Linus, please pull the latest core/debugobjects branch from: git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git core-debugobje= cts-2026-03-01 up to: fd3634312a04: debugobject: Make it work with deferred page initiali= zation - again A single fix for debugobjects. The deferred page initialization prevents debug objects from allocating slab pages until the initialization is complete. That causes depletion of the pool and disabling of debugobjects. The reason is that debugobjects uses __GFP_HIGH for allocations as it might be invoked from arbitrary contexts. When PREEMPT_COUNT is disabled there is no way to know whether the context is safe to set __GFP_KSWAPD_RECLAIM. This worked until v6.18. Since then 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. Work around that when PREEMPT_COUNT is enabled as the preempt counter 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. That makes debugobjects depend on PREEMPT_COUNT || !DEFERRED_STRUCT_PAGE_IN= IT, which limits the coverage slightly, but keeps it functional for most cases. Thanks, tglx ------------------> Thomas Gleixner (1): debugobject: Make it work with deferred page initialization - again lib/Kconfig.debug | 1 + lib/debugobjects.c | 19 ++++++++++++++++++- 2 files changed, 19 insertions(+), 1 deletion(-) diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug index ba36939fda79..a874146ad828 100644 --- a/lib/Kconfig.debug +++ b/lib/Kconfig.debug @@ -723,6 +723,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 diff --git a/lib/debugobjects.c b/lib/debugobjects.c index 89a1d6745dc2..12f50de85b62 100644 --- 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);