debugobject: Make it work with deferred page initialization - again
Subsystems (2)
Thomas Gleixner
maintainerdebugobjects 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_INIT.
--- lib/Kconfig.debug | 1 + lib/debugobjects.c | 19 ++++++++++++++++++- 2 files changed, 19 insertions(+), 1 deletion(-)
lib/Kconfig.debug +1 -0
@@ -753,6 +753,7 @@ source "mm/Kconfig.debug" 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
lib/debugobjects.c +18 -1
@@ -398,9 +398,26 @@ static void fill_pool(void)atomic_inc (&cpus_allocating);while (pool_should_refill (&pool_global)) { +gfp_t gfp = __GFP_HIGH | __GFP_NOWARN;HLIST_HEAD (head); -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 |= __GFP_KSWAPD_RECLAIM; + +if (!kmem_alloc_batch (&head, obj_cache, gfp))break ;guard (raw_spinlock_irqsave)(&pool_lock);
Alexei Starovoitov
Acked-byQuoted 19 lines · Thomas Gleixner
debugobjects uses
__GFP_HIGHfor 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 inalloc_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_COUNTis enabled as that allows debugobjects to add__GFP_KSWAPD_RECLAIMto the GFP flags when the context is preemtible. WhenPREEMPT_COUNTis 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.
Quoted 7 lines
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_INIT.Fixes af92793e52c3 ("slab: Introduce kmalloc_nolock() and kfree_nolock().")Signed-off-by Thomas Gleixner <[email protected]>
Tricky. The patch makes sense to me.
Vlastimil Babka
Acked-byQuoted 18 lines · Thomas Gleixner
debugobjects uses
__GFP_HIGHfor 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 inalloc_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_COUNTis enabled as that allows debugobjects to add__GFP_KSWAPD_RECLAIMto the GFP flags when the context is preemtible. WhenPREEMPT_COUNTis 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.
Quoted 7 lines
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_INIT.Fixes af92793e52c3 ("slab: Introduce kmalloc_nolock() and kfree_nolock().")Signed-off-by Thomas Gleixner <[email protected]>
Quoted 45 lines
--- lib/Kconfig.debug | 1 + lib/debugobjects.c | 19 ++++++++++++++++++- 2 files changed, 19 insertions(+), 1 deletion(-)lib/Kconfig.debug +1
-0@@ -753,6 +753,7 @@ source "mm/Kconfig.debug" 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 thelib/debugobjects.c +18
-1@@ -398,9 +398,26 @@ static void fill_pool(void)atomic_inc (&cpus_allocating);while (pool_should_refill (&pool_global)) { +gfp_t gfp = __GFP_HIGH | __GFP_NOWARN;HLIST_HEAD (head); -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 |= __GFP_KSWAPD_RECLAIM; + +if (!kmem_alloc_batch (&head, obj_cache, gfp))break ;guard (raw_spinlock_irqsave)(&pool_lock);
Sebastian Andrzej Siewior
Tested-byQuoted 5 lines · Thomas Gleixner
That makes debugobjects depend on
PREEMPT_COUNT|| !DEFERRED_STRUCT_PAGE_INIT.Fixes af92793e52c3 ("slab: Introduce kmalloc_nolock() and kfree_nolock().")Signed-off-by Thomas Gleixner <[email protected]>
Sebastian
The following commit has been merged into the core/debugobjects branch of tip:
The following commit has been merged into the core/debugobjects branch of tip:
Commit-ID: 998d5a6164d9fb33224f24b3e36dac0a8b0496e5 Gitweb: https://git.kernel.org/tip/998d5a6164d9fb33224f24b3e36dac0a8b0496e5 Author: Thomas Gleixner <[email protected]> AuthorDate: Sat, 07 Feb 2026 14:27:05 +01:00 Committer: Thomas Gleixner <[email protected]> CommitterDate: Tue, 10 Feb 2026 11:47:35 +01:00
debugobject: Make it work with deferred page initialization - again
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_INIT.
--- lib/Kconfig.debug | 1 + lib/debugobjects.c | 19 ++++++++++++++++++- 2 files changed, 19 insertions(+), 1 deletion(-)
lib/Kconfig.debug +1 -0
@@ -723,6 +723,7 @@ source "mm/Kconfig.debug" 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
lib/debugobjects.c +18 -1
@@ -398,9 +398,26 @@ static void fill_pool(void)atomic_inc (&cpus_allocating);while (pool_should_refill (&pool_global)) { +gfp_t gfp = __GFP_HIGH | __GFP_NOWARN;HLIST_HEAD (head); -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 |= __GFP_KSWAPD_RECLAIM; + +if (!kmem_alloc_batch (&head, obj_cache, gfp))break ;guard (raw_spinlock_irqsave)(&pool_lock);
The following commit has been merged into the core/debugobjects branch of tip:
The following commit has been merged into the core/debugobjects branch of tip:
Commit-ID: fd3634312a04f336dcbfb481060219f0cd320738 Gitweb: https://git.kernel.org/tip/fd3634312a04f336dcbfb481060219f0cd320738 Author: Thomas Gleixner <[email protected]> AuthorDate: Sat, 07 Feb 2026 14:27:05 +01:00 Committer: Thomas Gleixner <[email protected]> CommitterDate: Tue, 10 Feb 2026 13:26:19 +01:00
debugobject: Make it work with deferred page initialization - again
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_INIT.
--- lib/Kconfig.debug | 1 + lib/debugobjects.c | 19 ++++++++++++++++++- 2 files changed, 19 insertions(+), 1 deletion(-)
lib/Kconfig.debug +1 -0
@@ -723,6 +723,7 @@ source "mm/Kconfig.debug" 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
lib/debugobjects.c +18 -1
@@ -398,9 +398,26 @@ static void fill_pool(void)atomic_inc (&cpus_allocating);while (pool_should_refill (&pool_global)) { +gfp_t gfp = __GFP_HIGH | __GFP_NOWARN;HLIST_HEAD (head); -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 |= __GFP_KSWAPD_RECLAIM; + +if (!kmem_alloc_batch (&head, obj_cache, gfp))break ;guard (raw_spinlock_irqsave)(&pool_lock);
Quoted 18 lines · Thomas Gleixner
debugobjects uses
__GFP_HIGHfor 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 inalloc_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_COUNTis enabled as that allows debugobjects to add__GFP_KSWAPD_RECLAIMto the GFP flags when the context is preemtible. WhenPREEMPT_COUNTis 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.
Quoted 7 lines
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_INIT.Fixes af92793e52c3 ("slab: Introduce kmalloc_nolock() and kfree_nolock().")Signed-off-by Thomas Gleixner <[email protected]>
FYI, it should now be possible to revert this workaround:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=335c347686e76df9d2c7d7f61b5ea627a4c5cb4c
Quoted 46 lines
--- lib/Kconfig.debug | 1 + lib/debugobjects.c | 19 ++++++++++++++++++- 2 files changed, 19 insertions(+), 1 deletion(-)lib/Kconfig.debug +1
-0@@ -753,6 +753,7 @@ source "mm/Kconfig.debug" 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 thelib/debugobjects.c +18
-1@@ -398,9 +398,26 @@ static void fill_pool(void)atomic_inc (&cpus_allocating);while (pool_should_refill (&pool_global)) { +gfp_t gfp = __GFP_HIGH | __GFP_NOWARN;HLIST_HEAD (head); -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 |= __GFP_KSWAPD_RECLAIM; + +if (!kmem_alloc_batch (&head, obj_cache, gfp))break ;guard (raw_spinlock_irqsave)(&pool_lock);
Thomas Gleixner
maintainerQuoted 11 lines · Vlastimil Babka
Quoted 7 lines · Thomas Gleixner
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_INIT.Fixes af92793e52c3 ("slab: Introduce kmalloc_nolock() and kfree_nolock().")Signed-off-by Thomas Gleixner <[email protected]>FYI, it should now be possible to revert this workaround:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=335c347686e76df9d2c7d7f61b5ea627a4c5cb4c
Cool.