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 62D7D2AD35 for ; Tue, 2 Dec 2025 05:48:21 +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=1764654501; cv=none; b=AjkmAMSUrhfFO7QQX30FxLNdozs/nLFr3teRrB596MTiNRlafMT07dMBNsYoY4LmlljuweaC5dSdh4bmfrWJQVGGgdwD+Slth423bqqDsDr9kN8ht02WCDYTwCgLLD8Z3iaBF0CYE7KWV/TOMYQG102q7DJtLi3BzUA2Bu8Or40= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764654501; c=relaxed/simple; bh=F/5OJ82ExP+be5jimLL3WIMIaFGuTw3YZOCBfW4Zty0=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=Uw+fyqI/eWs8UxrYmDJy+hV4yibAYR+S/1K/mqUL9v6cDr0Er4ZxiKJu//+0H4UzL6kFYWFCZiwzSXY9gNXwlZfOJLb/8vFZjq0dZpnBTysD5X2Z/5ITM09tVq6p3GoxlVQTF3GAMqZ/ZGKVm/t6m2lDKynnB//amB9OKiIYEDE= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=o4fMCBLW; 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="o4fMCBLW" Received: by smtp.kernel.org (Postfix) with ESMTPSA id BC9DFC4CEF1; Tue, 2 Dec 2025 05:48:20 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1764654501; bh=F/5OJ82ExP+be5jimLL3WIMIaFGuTw3YZOCBfW4Zty0=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=o4fMCBLWIsCy6cT2wMH+jIIwPKQ6s4d9+9WzpMbFLY/1ViSzFYrWMryG42rI7g059 mG81LHFmkM4/bwCPxdFyz8iiRdbmUqLM+J4A6WQ/36WP40iUP12xdbnD6REIEPuFcM xTnKl9pfKfD2RB1ke3V725ubSLpEh+yALOWPJ/qRSnmHiV/b5RamL1iQfUHYDAwNXU EP+ZYWQ2GXHWbbhgGZ4J0lxoEfHJlRjA1LY3OuDZFBI9fnafj8qhVv6GtCKW8tXGzt Q+BI5yoMyz0AKtsb7mSyY24bL9/sSp4e69R0EUlsbQIldT/iREO3QoLkkkNvJm40dT Z/32OzgELlsgA== Date: Mon, 1 Dec 2025 19:48:19 -1000 From: Heo To: =?utf-8?B?6K645Lic5rSB?= Cc: Zijlstra , Jiangshan , Molnar , Deacon , Feng , Long , linux-kernel@vger.kernel.org Subject: Re: [BUG] lockdep: MAX_LOCKDEP_KEYS too low when destroying workqueues Message-ID: References: <34e8a1ee.3323c.19ad4011944.Coremail.xudongjie25@mails.ucas.ac.cn> 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=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <34e8a1ee.3323c.19ad4011944.Coremail.xudongjie25@mails.ucas.ac.cn> On Sun, Nov 30, 2025 at 05:03:53PM +0800, 许东洁 wrote: > Hello, > > I found a lockdep issue using syzkaller where repeatedly destroying workqueues exhausts > MAX_LOCKDEP_KEYS and disables the lock validator. > > The bug triggers through: > nci_unregister_device -> destroy_workqueue -> drain_workqueue -> touch_wq_lockdep_map > > Kernel output: > BUG: MAX_LOCKOCKDEP_KEYS too low! > turning off the locking correctness validator. > > It appears workqueue lock classes are not properly released in destroy_workqueue, > causing lock class leakage. Looks like the repro ends up creating and destroying workqueues back to back. Part of workqueue destruction is asynchronous, so if you do that quickly enough, running out of lockdep keys isn't that surprising. I'm not sure this is a meaningful bug report. Thanks. -- tejun