From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-dy1-f173.google.com (mail-dy1-f173.google.com [74.125.82.173]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id B5AB44A32 for ; Mon, 29 Jun 2026 04:11:29 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=74.125.82.173 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782706291; cv=none; b=YQwzR9bt8jB1CkeUNLkO6S4i11n6NiA0atDpYb1cEo3FwQvRDNnS8eMQZObPIP7Wmbr0bFVr0rtyxdY8hk3Py4hmLPtOYt6FyY7zY0SVA1dQb5Vj3ItwlEdmPhe6tw5mfV+bo189dWdjda2nhSP+G1ART1GYGYOFEfNBKMWSi2o= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782706291; c=relaxed/simple; bh=khi7jXUbSNp0BTOwk9TtxdRZME/VNJvAyRwPPryVMI4=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=OGC4j3o8/V/8CjiKMUBvFeOo8NHTIYsJQ7fGLenF0HCbpRanRXaH+SCwoi04VLqXAe35GL4Fo3i3v9p6paU8iAFeZXvMp2+ed1eHRXz9NxV3SKiNdpvtSj08l1/LMlwSmqQ67ag3tB/G08hPEUfZhyuMBypOWtyNjSBK4fM3jbA= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=grn1UQ/A; arc=none smtp.client-ip=74.125.82.173 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="grn1UQ/A" Received: by mail-dy1-f173.google.com with SMTP id 5a478bee46e88-30b6dad2382so5440273eec.0 for ; Sun, 28 Jun 2026 21:11:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1782706289; x=1783311089; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=5+f0Hfa5i5sgiXXNUN3tfuXSD/K6Kf4kdBHTzC4HYyU=; b=grn1UQ/AdOXVLVpU6D2WngAJYQbcM+QmR3CL9pmJYANnddlGRKSgsIkZ7zoTvkUX0o t1orgsxWm8MBleO9mGmmni3v3QHdd3UXMyuoUzwmDJRxV0aioieVbb6bUPZm4NjYb5FX tUakIyprJ4VV5bRGR1AIKtT9SZpfbeUNyJ9lFZ1kJhvTCTf3CeDFockpgVDkpuhCieP2 3bfZSHXa2K9w8xw6JiKLvXCx84s7te6tvyr1wEXAGxinwjUq5tCTIl5EGSv8hSs+Fr3V WjHno2N3WP8XS0IPLka2WDhX3eDiCNDpRivTgcqSzBy15DNx2tTWWe/ZBBiaL7yapE7S l1dw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1782706289; x=1783311089; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=5+f0Hfa5i5sgiXXNUN3tfuXSD/K6Kf4kdBHTzC4HYyU=; b=jV+XV4pHL1MwWpXWWBJKJFrAVz0N2QjHK5zRlxpsLK7vU6jXjiAzWlXVGKJiQBgFGf fOhyHmUgzxYg5S1GN1A4mpKYV88oi1a9fJpXPe+S1gDBZxnCagAQd4s+qMVob7zO1V2f HGmEF034TCuxa6vzenh1BWjCGC5qQsBoC5FIRnnreuwkxauaIgiKMBmGkigmhaNJ4TZN Rouy2q/8Sj/Ntp+WNRonjkrRfv7Df29C7NRcDLxBWOSmDATAzYRZnKi9ehx9QVHLrxWE T48zS4ck8aE/hSGQoXa1jCjgc6cAtIRrR8jhlPFOm4Juw9sXlaRMmKC9Rb7StIMCypzZ g8Qw== X-Gm-Message-State: AOJu0Yzxsmz3t+uT8+FqzY/DK2KgddwiN1wP4UKC+DrYgaWqq4c1PWgX V/5WgT8K5ESbahO8iYIGg9+naaN722x5jCE8sylDHKnZHAeSAfdGMrNg X-Gm-Gg: AfdE7cksCCv5zKUrOcKosH4+UAZqVuBrJKLztXF0r/Hwx96v90O1UZFPB0AMsPlgSvz 5zoflSH4CcVNU8Jij4LIZQ7Vw3MzcpWRsuBKC5e51se3Kz7XoXZnLpxsYtoQs+iViwCbC6lOyLk X/sWK+V10+t/KMGUNDqwvkFy1im3gvnCksE3Gkzfy5lfDzel/WkSMJ93FGHuBPheuuWE94lw99R 6TipAkBk9gY6Zlrj4ZMnIS60DlQlBjlJt64a3/ZKJrfAYxjTG0Uj35SnT9F/bYM7xehj6RzEpnq UGw1Oe84nfJsD6od9p0S9DmNaE9pgW19Q/5bE4uZAj0tRNnafM/6y1ZD1txxcg2dz8PLmWdAkEm Ip5qtG/TevL0w0ukYbm1knglNgLQJRBDfQA9EpS3BK10g4rgdPfGR2+VeVO5DCrvAQP2gJTT4/z flVhm1DbpQwlJUtRGDgVe4IkRNzffjKz/+4PQfeL+pLa1oKTzjU20swQ0sIfYCSCr/F4/U X-Received: by 2002:a05:7300:6d23:b0:30e:c38f:eaa8 with SMTP id 5a478bee46e88-30ec38ffbc9mr3596241eec.4.1782706288598; Sun, 28 Jun 2026 21:11:28 -0700 (PDT) Received: from deepanshu-kernel-hacker.. ([2405:201:682f:383f:44ac:bd07:a8d1:1c27]) by smtp.gmail.com with ESMTPSA id 5a478bee46e88-30ec3e400a2sm11537380eec.28.2026.06.28.21.11.24 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 28 Jun 2026 21:11:28 -0700 (PDT) From: Deepanshu Kartikey To: peterz@infradead.org, mingo@redhat.com, will@kernel.org, boqun@kernel.org, longman@redhat.com Cc: linux-kernel@vger.kernel.org, Deepanshu Kartikey , syzbot+0635dc2e2c3c21a6aa04@syzkaller.appspotmail.com Subject: [PATCH] locking/lockdep: skip irq save/restore in hardirq context in lock_release() Date: Mon, 29 Jun 2026 09:41:19 +0530 Message-ID: <20260629041119.87790-1-kartikey406@gmail.com> X-Mailer: git-send-email 2.43.0 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit lock_release() performs a raw_local_irq_save/restore dance around its validation work. While safe in process and softirq context, this is dangerous in hardirq context where IRQs must remain disabled for the entire duration of the handler. When lock_release() calls raw_local_irq_restore() inside a hardirq handler, it briefly re-enables IRQs, creating a window where a new interrupt can fire before the handler returns. This was observed with taprio's advance_sched() hrtimer callback - the temporary IRQ re-enablement inside lock_release() prevented CPU 0 from acknowledging a pending TLB flush IPI sent by CPU 1 via smp_call_function_many(). CPU 1 then spun indefinitely in csd_lock_wait(), starving the RCU grace-period kthread and triggering an RCU stall with eventual OOM. lock_acquire() already handles the NMI case specially via lockdep_nmi() to avoid this class of problem. Mirror that pattern for hardirq context in lock_release() by introducing lockdep_hardirq() and skipping the irq save/restore dance when called from hardirq context. Reported-by: syzbot+0635dc2e2c3c21a6aa04@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=0635dc2e2c3c21a6aa04 Signed-off-by: Deepanshu Kartikey --- kernel/locking/lockdep.c | 17 +++++++++++++++++ 1 file changed, 17 insertions(+) diff --git a/kernel/locking/lockdep.c b/kernel/locking/lockdep.c index 2d4c5bab5af8..17eb9590e751 100644 --- a/kernel/locking/lockdep.c +++ b/kernel/locking/lockdep.c @@ -5872,6 +5872,15 @@ void lock_acquire(struct lockdep_map *lock, unsigned int subclass, } EXPORT_SYMBOL_GPL(lock_acquire); +static bool lockdep_hardirq(void) +{ + if (raw_cpu_read(lockdep_recursion)) + return false; + if (!in_hardirq()) + return false; + return true; +} + void lock_release(struct lockdep_map *lock, unsigned long ip) { unsigned long flags; @@ -5882,6 +5891,14 @@ void lock_release(struct lockdep_map *lock, unsigned long ip) lock->key == &__lockdep_no_track__)) return; + if (lockdep_hardirq()) { + lockdep_recursion_inc(); + if (__lock_release(lock, ip)) + check_chain_key(current); + lockdep_recursion_finish(); + return; + } + raw_local_irq_save(flags); check_flags(flags); -- 2.43.0