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 049243D3339 for ; Wed, 5 Aug 2026 19:29:53 +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=1785958195; cv=none; b=khTKVXILcGdv+Empysr+YrdK3Ds91H+JuvIhg8/4Ia5wdXIPLHnYq6u0VEyQhZ6M47FTQECMl5CEVT0cRDdINmDi/ukSrBL3U4diUP0x70nCXSJ49XXa/DafeG4l6ck3rB3bLk61YnbglQHukgEJ/4aNmuDMwi+DBRP5Z2/GFM4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785958195; c=relaxed/simple; bh=t0H0X5rBn2Lx5uSfkBQBkV6BzmCqHI7LKw3HHeRF45Q=; h=Date:From:To:Cc:Subject:Message-Id:In-Reply-To:References: Mime-Version:Content-Type; b=kJSZgZYo0l4qf+Y4Xx92SZBQclfbSp7N4dsuhHVI75xVUzm/T49a1i8CqhNIu94LVSjdP5pVLYMhdeO4nhgFa9++gLkSWoLO53M9Gb2Md0QkNJoAOvof2GtIp+H/G0wjQ04ZR/Rxi4Ci2hjamQA3z5lV6DxaBRlI1093ErUPPvE= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux-foundation.org header.i=@linux-foundation.org header.b=ddXl1mwi; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux-foundation.org header.i=@linux-foundation.org header.b="ddXl1mwi" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 354AB1F000E9; Wed, 5 Aug 2026 19:29:53 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=korg; t=1785958193; bh=elA1Ms4Gn/MoVQix4/8a+mH7M22rfFyFqVGiYAr4QAc=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=ddXl1mwiNzIIB+yCm/bWxetoXBwryCujiM6Iar1NzfSxbqsd/zqXnVjuwPJPisVje NMJlB97zWZ1OCO56xatydk1M6zkMUbL/opllmxgSpe09KzTORuRbnYiRosv2Db61/z 7c2PgcGWEk44csfDq2Sa9PQOD5jgEMsmlkAkQ51c= Date: Wed, 5 Aug 2026 12:29:52 -0700 From: Andrew Morton To: syzbot Cc: 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, "Paul E. McKenney" Subject: Re: [syzbot] [mm?] INFO: rcu detected stall in khugepaged (3) Message-Id: <20260805122952.6ae38af69a0457779cb44359@linux-foundation.org> In-Reply-To: <6a727d6c.9511d2ce.1fc5b9.035e.GAE@google.com> References: <6a727d6c.9511d2ce.1fc5b9.035e.GAE@google.com> X-Mailer: Sylpheed 3.8.0beta1 (GTK+ 2.24.33; x86_64-pc-linux-gnu) 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-Transfer-Encoding: 7bit On Tue, 04 Aug 2026 17:01:48 -0700 syzbot wrote: > Hello, > > syzbot found the following issue on: > > HEAD commit: 3708dd948844 Merge tag 'pm-7.2-rc6' of git://git.kernel.or.. > git tree: upstream > console output: https://syzkaller.appspot.com/x/log.txt?x=11ac703e580000 > kernel config: https://syzkaller.appspot.com/x/.config?x=4e38b15c29e6a1d9 > dashboard link: https://syzkaller.appspot.com/bug?extid=d2401aeb74cc84adba04 > compiler: Debian clang version 22.1.8 (++20260613092233+e80beda6e255-1~exp1~20260613092250.77), Debian LLD 22.1.8 > > Unfortunately, I don't have any reproducer for this issue yet. Thanks. Lazy optimists (ahem) paste this gunk into Gemini and ask "what the heck just happened". The results are often useful, but should be treated with skepticism. In this case I think it came usably close. https://share.gemini.google/vq4TLhTiLBih tl;dr: khugepaged's collapse_scan_file() is taking too long and RCU got starved. I don't think khugepaged is doing anything wrong here, per-se. There's a lot of work to do and we're doing it. An appropriate fix would be to take a break, let RCU do its thing then get back to work. But I don't think RCU offers interfaces for that? 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?