From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (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 F04103955FE for ; Thu, 6 Aug 2026 16:27:44 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786033666; cv=none; b=EnPGCXb5duEnkEDpbjK3sZya3tRvobRoV1QGfELbVCPL1cTdNAwpbMev9KRXVVh8vqLDTQHC+dfqE2FoaPCqEBQU7BfNxhiMR7hJBDl4cKkR6i1rpyD8ijvRm+D6CbrkDAiNeSmFUKnKmNK22GPGZ3u28p51PX39Tk8mmVpOGN4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786033666; c=relaxed/simple; bh=4UJAO9j+dPbQ06nTZ5NrgRs9OqQakIh3S0JWrqreqHc=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=pxLbzkU+iKybdZy0v/5nwRPo09AfCkGTFeRhAXO1wxPt+u8Tk+R9NTDccThqo/hcz0SKb2dfZrxB6ONrUx/uGJDw2ErBp4tJVI6Q9GsBmbJrjdU669yrG4jqlTy7XMYqCMUv+CpFu0Um4bGnVVGcZmKj6GA6AkxPKgufTS4LEs0= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=PnMQqzx5; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="PnMQqzx5" Received: by smtp.kernel.org (Postfix) with ESMTPSA id D272A1F00A3D; Thu, 6 Aug 2026 16:27:44 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1786033664; bh=TOGeScaSuHuM7HfCCnzcathOZlLZGsTyN9pqp0ZRFi0=; h=Date:From:To:Cc:Subject:Reply-To:References:In-Reply-To; b=PnMQqzx5rsg7Ra7zFrqozPwGU8Did/cXOmsuwLwdhIB7m9yjhSYt+LAuF8eqJl/Ua Bkeq+0eV61PXx7RCcHa7KpweT3yh/fckRCqMBf4cj4reHaMPJmPt1ofcQu9GQIyAJ3 3Q7arpxDWVhexwxryVjkPXTGN8TmvUu7g1+Wkdz9UgqZJJ8cclDtVVBH6e10QPYI+J 0zThl8+/N82Y2QfFwDk92k3TvxMnf2k9u33SpY80yOwQZk1iZk9amoljpg1Cu5O2M9 CugVlERvMAuCrqfEG9LvviMu2o7sUlrVL9G9aN049OiN8iribLMzdBeVAD6uj/LsUg vfcllhNsnKu+Q== Received: by paulmck-ThinkPad-P17-Gen-1.home (Postfix, from userid 1000) id 64615CE19F3; Thu, 6 Aug 2026 09:27:44 -0700 (PDT) Date: Thu, 6 Aug 2026 09:27:44 -0700 From: "Paul E. McKenney" To: Andrew Morton Cc: syzbot , hannes@cmpxchg.org, jackmanb@google.com, linux-kernel@vger.kernel.org, linux-mm@kvack.org, mhocko@suse.com, surenb@google.com, syzkaller-bugs@googlegroups.com, vbabka@kernel.org, ziy@nvidia.com Subject: Re: [syzbot] [mm?] INFO: rcu detected stall in khugepaged (3) Message-ID: <3fca260a-4544-4e65-916e-d2ef7fa1440f@paulmck-laptop> Reply-To: paulmck@kernel.org References: <6a727d6c.9511d2ce.1fc5b9.035e.GAE@google.com> <20260805122952.6ae38af69a0457779cb44359@linux-foundation.org> <20260805230311.2bbda85fb92abcf12d85194e@linux-foundation.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20260805230311.2bbda85fb92abcf12d85194e@linux-foundation.org> On Wed, Aug 05, 2026 at 11:03:11PM -0700, Andrew Morton wrote: > On Wed, 5 Aug 2026 13:28:16 -0700 "Paul E. McKenney" wrote: > > > > collapse_scan_file()'s main loop has > > > > > > if (need_resched()) { > > > xas_pause(&xas); > > > cond_resched_rcu(); > > > } > > > > > > but that won't help with the RCU stall detector(?). > > > > > > I suggest that a suitable fix here would be to add the analogous > > > > > > if (rcu_i_need_to_take_a_break()) { > > > rcu_read_unlock(); > > > rcu_take_a_break()) > > > rcu_read_lock(); > > > } > > > > > > (iirc rcu_read_unlock() does an rcu run, so rcu_take_a_break() isn't > > > needed here) > > > > > > Paul, wdyt? > > > > Let's see... > > > > The console log says "rcu_preempt detected stalls on CPUs/tasks", > > which means that cond_resched() is a no-op, but it also means that > > the rcu_read_unlock() in cond_resched_rcu() will directly take care of > > informing RCU of the pause. > > > > But that is clearly not happening. Why? > > > > Well, we have this: > > > > rcu: Tasks blocked on level-0 rcu_node (CPUs 0-1): P37/1:b..l > > > > This means that the task whose RCU read-side critical section is blocking > > the current RCU grace period isn't even running, and thus cannot invoke > > cond_resched_rcu(), let alone the rcu_read_unlock() within that function. > > So an RCU CPU stall warning is expected behavior. Or at least it is not > > in any way ruled out. > > > > What we need is RCU priority boosting. > > Do we? I'm suggesting we need need_resched_rcu()! Understood, and I initially agreed with you. Except that I then found that the poor preempted task isn't executing anything at all. Which means that an added need_resched_rcu() cannot possibly help. > > Except that the .config file > > does not enable this. Not only is there no CONFIG_RCU_BOOST=y, there > > is also no CONFIG_RCU_EXPERT=y and no CONFIG_PREEMPT_RT=y. But there > > is CONFIG_RT_MUTEX=y and CONFIG_RCU_EXPERT=y. > > > > Because we don't have RCU priority boosting, if the load on the system > > is heavy enough to prevent our poor preempted RCU reader (PID 37) from > > running, the grace period cannot end. > > > > I am not sure why this task is saving its stack, but maybe that is normal > > for this code path? > > > > My bemusement aside, I recommend running this test either with > > non-preemptible RCU (CONFIG_PREEMPT_LAZY=y these days) or enabling RCU > > priority boosting (CONFIG_RCU_EXPERT=y and CONFIG_RCU_BOOST=y). > > > > Maybe RCU_BOOST should no longer depend on RCU_EXPERT? I would of > > course need ot remove the prompt ("Enable RCU priority boosting") to > > avoid annoying Linus. Maybe as shown below. > > > > Thoughts? > > If I'm understanding correctly, this workload is busted with this > config and the proposed fix is to alter the config? Well, why are we > permitting that config at all? Agreed, and my proposal is in fact to remove that config. This assumes that CONFIG_RCU_BOOST is ready for prime time, and given that I have been testing it for years and that CONFIG_PREEMPT_RT has been using it for years, I am cautiously optimistic. > Seems to me that a solution to permit this config to work is very > simple. Something like: > > time_t start; > > rcu_read_lock(); > start = current_time(); > > for (lots of work) { > ... > if (need_resched_rcu(start)) { > cond_resched_rcu(); > start = current_time(); > } > > Where need_resched_rcu() tests to see if we're getting close to hitting > the watchdog timeout. > > No? No. Added code doesn't help a task that has been preempted for some seconds and thus isn't executing any code at all. The task has been preempted while within an RCU read-side critical section. The sequence of events is as follows: rcu_read_lock(); // preempted for many tens of seconds. cond_resched_rcu(); // doesn't help because it is never executed. rcu_read_unlock(); Or am I missing your point? Thanx, Paul