From mboxrd@z Thu Jan 1 00:00:00 1970 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 0900122156F; Fri, 23 Jan 2026 08:48:05 +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=1769158085; cv=none; b=XhhGS6CsE0mvmZsbHl2RNMypukzKT85yhmleb2pWYm6n36AxZE7SxRuXfzOZy1/u/XXUuArhPkkZ9V5WTJp1Abg4021tOp2mzt5fi+Z+tmpsQPgyPeCX+fpwm1/WgR1wxBoA+nJbzUcpyRoofV5mMpFi8ePFXkJQ7lq2WL+zw1g= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769158085; c=relaxed/simple; bh=rVZ2b/M2elvLd9oSAfscYONQkqOhn+v+x4ixSf7WcUM=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=KdZr7/pQUYtKmoHker9z//hhryGyAMgUL7Jxmu00SZPTbxUtfpJJkV8pBVaxNJOhqv141cX2MfWhQdDSnVeB5P+XGFYZe3m3p4sq985bt4oTQN4AFK2RUXv+joDohkrbOiUOrzEK3A57xVrItKfsSEvteDxgEhUlzdnGZBda54s= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=iZzwfhrI; 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="iZzwfhrI" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 4844CC4CEF1; Fri, 23 Jan 2026 08:48:00 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1769158084; bh=rVZ2b/M2elvLd9oSAfscYONQkqOhn+v+x4ixSf7WcUM=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=iZzwfhrI7qdWTFJkOeg6GtD3NUpF7uCWTGgbKZHOntekUsH4J8JTvqW098ocRzCy0 mkyk34UKQ6jFs/HDYw8akI+8dVLf/sfLOnkMsQeOIYAb4cHB6gE6TFo+FONSuXd73N Vu0cIVG8TuunkM+qmIumzCLiv6A1OgNaNJU1No5O+eygLfxX/seRfMLgp/l8T+w2q7 ciGhYonIXO7EiE3bolXMNWxS+RP3HDORF3q+vul0iG/GLFV50NkZpyJ6sDlYd5ZZEP hqajgJBbFBqFs2rsVOfURvyIB2OoEsKKhF5uTnpjlk08FLcuYCl1FUnHl4EroNDEDC o2a3FepxtRh/w== Date: Fri, 23 Jan 2026 10:47:57 +0200 From: Mike Rapoport To: Waiman Long Cc: Andrew Morton , Sebastian Andrzej Siewior , Clark Williams , Steven Rostedt , linux-mm@kvack.org, linux-kernel@vger.kernel.org, linux-rt-devel@lists.linux.dev, Wei Yang , David Hildenbrand , "Paul E . McKenney" Subject: Re: [PATCH v3] mm/mm_init: Don't cond_resched() in deferred_init_memmap_chunk() if called from deferred_grow_zone() Message-ID: References: <20260122184343.546627-1-longman@redhat.com> Precedence: bulk X-Mailing-List: linux-rt-devel@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20260122184343.546627-1-longman@redhat.com> On Thu, Jan 22, 2026 at 01:43:43PM -0500, Waiman Long wrote: > Commit 3acb913c9d5b ("mm/mm_init: use deferred_init_memmap_chunk() > in deferred_grow_zone()") made deferred_grow_zone() call > deferred_init_memmap_chunk() within a pgdat_resize_lock() critical > section with irqs disabled. It did check for irqs_disabled() in > deferred_init_memmap_chunk() to avoid calling cond_resched(). For a > PREEMPT_RT kernel build, however, spin_lock_irqsave() does not disable > interrupt but rcu_read_lock() is called. This leads to the following > bug report. > > BUG: sleeping function called from invalid context at mm/mm_init.c:2091 > in_atomic(): 0, irqs_disabled(): 0, non_block: 0, pid: 1, name: swapper/0 > preempt_count: 0, expected: 0 > RCU nest depth: 1, expected: 0 > 3 locks held by swapper/0/1: > #0: ffff80008471b7a0 (sched_domains_mutex){+.+.}-{4:4}, at: sched_domains_mutex_lock+0x28/0x40 > #1: ffff003bdfffef48 (&pgdat->node_size_lock){+.+.}-{3:3}, at: deferred_grow_zone+0x140/0x278 > #2: ffff800084acf600 (rcu_read_lock){....}-{1:3}, at: rt_spin_lock+0x1b4/0x408 > CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Tainted: G W 6.19.0-rc6-test #1 PREEMPT_{RT,(full) > } > Tainted: [W]=WARN > Call trace: > show_stack+0x20/0x38 (C) > dump_stack_lvl+0xdc/0xf8 > dump_stack+0x1c/0x28 > __might_resched+0x384/0x530 > deferred_init_memmap_chunk+0x560/0x688 > deferred_grow_zone+0x190/0x278 > _deferred_grow_zone+0x18/0x30 > get_page_from_freelist+0x780/0xf78 > __alloc_frozen_pages_noprof+0x1dc/0x348 > alloc_slab_page+0x30/0x110 > allocate_slab+0x98/0x2a0 > new_slab+0x4c/0x80 > ___slab_alloc+0x5a4/0x770 > __slab_alloc.constprop.0+0x88/0x1e0 > __kmalloc_node_noprof+0x2c0/0x598 > __sdt_alloc+0x3b8/0x728 > build_sched_domains+0xe0/0x1260 > sched_init_domains+0x14c/0x1c8 > sched_init_smp+0x9c/0x1d0 > kernel_init_freeable+0x218/0x358 > kernel_init+0x28/0x208 > ret_from_fork+0x10/0x20 > > Fix it adding a new argument to deferred_init_memmap_chunk() to > explicitly tell it if cond_resched() is allowed or not instead of > relying on some current state information which may vary depending > on the exact kernel configuration options that are enabled. > > Fixes: 3acb913c9d5b ("mm/mm_init: use deferred_init_memmap_chunk() in deferred_grow_zone()") > Suggested-by: Sebastian Andrzej Siewior > Signed-off-by: Waiman Long Reviewed-by: Mike Rapoport (Microsoft) -- Sincerely yours, Mike.