From nobody Mon Sep 28 18:37:13 2026 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 E8F6F3EEAC2 for ; Tue, 18 Aug 2026 18:49:29 +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=1787078971; cv=none; b=fuWcH3YRyVh86Dt1FAVxSGGCKzD08Enn3DZH3LQ3WkIFVgWe9497ZGxOAZXuyR0LsYqzfFa5K/kwAb15r4kiwD92iYaysCmfTfiIb0pKDRy5D7YL7qqd6Lr7CsZC3ieWyvxxRsJJ3nhJfBOErbYlpZfBPwd0H85q/RUpfRLW8iM= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787078971; c=relaxed/simple; bh=SgT0f7puC/Xbvl4ACOb5ADaOugzzTDFc/iGsHw3Pnyw=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:Content-Type; b=gsYZdbuuDBuO1dKhAxk+Uaza74e8WV5OzpFB+OiH70b+nLPj6kJH4BGOl7APf3q7ZvY/8H28o+H3N8Ma0ED/7sHo9C7gFpIlf3ezDoJuUi8WPmDsiW+sA2rAhYGOIMz3DsFbS8UuhQALhL2sOkMu/+WJyK+zPM2QYPgXFM7vcms= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=G6ld22HO; 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="G6ld22HO" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 6A9A11F000E9; Tue, 18 Aug 2026 18:49:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1787078969; bh=OZbB+nKdOOdoTpm4SlQF/9WhtK9SYvpTPkJBgSCUqsg=; h=From:To:Cc:Subject:Date; b=G6ld22HOD0/17PiW9OuLkEIBli5ITpGwte2weCt1aR+FLyLaIRKCjE6WVK4O/ug8x igsE/pXZTEcuX4/XCTh+QXu0RQFU0twpmmegt3UwIBYSMFcaipgrR2qxgt1NzCLbQE hVZltQHAL4+pjRWdaGPXzNoFISPXrRhQjP23cJct2ch+AY3GJWoi6spu98G0oEATou dkothYXD01baueIVpSUU2FwUY+pUOjPn0eBADzMQ7bdZuAwiica9mWz30FHLGD3lFj k1mVXFBZmVSP5K0gfOXu6FYVZApC4wvjmfh//7MyPm8gnp2ke4G0yjAUeqFmpOotmy yX6YQvG/Sxobg== From: Tejun Heo To: Lai Jiangshan , Sebastian Andrzej Siewior , Thomas Gleixner , Peter Zijlstra Cc: syzbot+1bd20115328f8254ed62@syzkaller.appspotmail.com, syzkaller-bugs@googlegroups.com, linux-kernel@vger.kernel.org Subject: [PATCH wq/for-7.3] workqueue: Annotate cb_lock nesting when draining a dead BH pool Date: Tue, 18 Aug 2026 08:47:21 -1000 Message-ID: <178707884181.3094421.2098832455828801685@slm.duckdns.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="utf-8" Content-Transfer-Encoding: quoted-printable On PREEMPT_RT, bh_worker() wraps work item execution in pool->cb_lock to provide a handshake for canceling BH work items. When a CPU goes down, drain_dead_softirq_workfn() runs the dead pool's bh_worker() nested inside the local pool's bh_worker(), acquiring the cb_locks of two different pools without a nesting annotation. lockdep reports possible recursive locking: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D WARNING: possible recursive locking detected -------------------------------------------- ktimers/0/16 is trying to acquire lock: ffff8880b873a990 (&pool->cb_lock){+...}-{3:3}, at: bh_worker+0x7d/0x880 but task is already holding lock: ffff8880b863a990 (&pool->cb_lock){+...}-{3:3}, at: bh_worker+0x7d/0x880 Call Trace: bh_worker+0x7d/0x880 kernel/workqueue.c:3688 drain_dead_softirq_workfn+0x95/0x220 kernel/workqueue.c:3763 process_scheduled_works+0xa8e/0x14e0 kernel/workqueue.c:3405 bh_worker+0x46a/0x880 kernel/workqueue.c:3708 tasklet_action+0xc/0x70 kernel/softirq.c:965 The nesting can't deadlock. A pool's bh_worker() runs nested only while the pool's CPU is dead, entered from a live pool's bh_worker() on the draining CPU, so the ordering is always live to dead. CPU hotplug operations are serialized and the drain is synchronous, so the nesting depth never exceeds two. Annotate the inner acquisition with SINGLE_DEPTH_NESTING. Signed-off-by: Tejun Heo Reported-by: syzbot+1bd20115328f8254ed62@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=3D1bd20115328f8254ed62 Fixes: ad7c7f4b9c6c ("workqueue: Provide a handshake for canceling BH worke= rs") Cc: stable@vger.kernel.org # v6.18+ Reviewed-by: Sebastian Andrzej Siewior cb_lock); + /* + * SINGLE_DEPTH_NESTING is for a dead pool's bh_worker() running from + * drain_dead_softirq_workfn() inside a live pool's bh_worker(). The + * unlocked read is stable: the flag is only set while @pool's CPU is + * dead, inside a serialized hotplug operation. data_race() as the value + * only affects the lockdep annotation and the read can be elided when + * lockdep is disabled. + */ + spin_lock_nested(&pool->cb_lock, + data_race(pool->flags) & POOL_BH_DRAINING ? SINGLE_DEPTH_NESTING : 0); } =20 static void worker_unlock_callback(struct worker_pool *pool)