Received-SPF: pass (google.com: domain of linux-kernel+bounces-53146-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) client-ip=2604:1380:45d1:ec00::1;
Sender: Tejun Heo <htejun@gmail.com>
Date: Mon, 5 Feb 2024 07:46:48 -1000
From: Tejun Heo <tj@kernel.org>
To: "Paul E. McKenney" <paulmck@kernel.org>
Cc: Sergey Senozhatsky <senozhatsky@chromium.org>,
	Petr Mladek <pmladek@suse.com>,
	Jonas Oberhauser <jonas.oberhauser@huaweicloud.com>,
	Lai Jiangshan <jiangshanlai@gmail.com>,
	Steven Rostedt <rostedt@goodmis.org>,
	John Ogness <john.ogness@linutronix.de>,
	Stephen Rothwell <sfr@canb.auug.org.au>,
	linux-kernel@vger.kernel.org, rcu@vger.kernel.org
Subject: Re: [BUG] workqueues and printk not playing nice since next-20240130
Message-ID: <ZcEfCM160K5cnzHx@slm.duckdns.org>
References: <410d6a87-bf34-457e-b714-1e6149d48532@paulmck-laptop>
 <c6ce8816-c4ff-4668-8cbb-88285330057d@huaweicloud.com>
 <25fd8537-5a27-4b62-9bf9-1ee7ca59b5b8@paulmck-laptop>
 <Zb0evDquygkDI_8P@slm.duckdns.org>
 <c5d5ad66-da86-447b-8014-820d2c67382d@paulmck-laptop>
 <ZcDdlRzpofn2cAuO@alley>
 <20240205132515.GF69174@google.com>
 <a6762ad5-62f2-41d4-bba7-c2d9dcb12498@paulmck-laptop>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <a6762ad5-62f2-41d4-bba7-c2d9dcb12498@paulmck-laptop>

On Mon, Feb 05, 2024 at 09:45:53AM -0800, Paul E. McKenney wrote:
> On Mon, Feb 05, 2024 at 10:25:15PM +0900, Sergey Senozhatsky wrote:
> > On (24/02/05 14:07), Petr Mladek wrote:
> > > > Good point, if it does recur, I could try it on bare metal.
> > > 
> > > Please, me, John, and Sergey know if anyone see this again. I do not
> > > feel comfortable when there is problem which might make consoles calm.
> > 
> > Agreed.
> > 
> > > Bisection identified this commit:
> > > 5797b1c18919 ("workqueue: Implement system-wide nr_active enforcement for unbound workqueues")
> > 
> > That commit triggered early boot use-after-free (per kasan) on
> > my system, which probably could derail some things.
> 
> And enabling KASAN on next-20240130 got me that same KASAN report and
> also suppressed the misbehavior, which is not surprising given that
> KASAN quarantines free memory for some time.  Plus enabling KASAN
> on recent -next does not trigger that KASAN report.
> 
> So my guess is that we can attribute my oddball test failures to
> that use after free.  But I will of course continue testing.

Can someone paste the KASAN report?

Thanks.

-- 
tejun