From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pj1-f49.google.com (mail-pj1-f49.google.com [209.85.216.49]) (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 B4016191 for ; Mon, 29 Jun 2026 23:37:00 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.216.49 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782776221; cv=none; b=N7i5B7QgLOKB+pkAf4q+PvT+FDCn9A2iRwcbJwfWt+vRWBO8nD+q7renzsvKioxtSRV2Yd1OF7y9fJNJL/VWTX7wUjjdiAezvtNyxC3KkmDkG7XjOnQIO/Ac7/wnjg/FWPUPnXL84ytygCn9SUJmGzFYTYkWfIZAYxUQS6Bcrzg= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782776221; c=relaxed/simple; bh=6uiu4YaJ5RWFm+DKA6G692h5Fhl7pc9G2tm7MnbyywA=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=og13XF3vspxVBiS8lYEkmlVpHC9ONL994YXwhUlOA2BwxthGG5WLIVcPYF728RSzDSccQcKA4gAdfDO8V/yyPV0HNd8645AXucWCGklmoue48XyrMJIywpcYpom3qplkOSV4tdR6D1ZCtGXGhpHI682DnbRy7apRU2MFdmVtviY= 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=JqoWmOVM; arc=none smtp.client-ip=209.85.216.49 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="JqoWmOVM" Received: by mail-pj1-f49.google.com with SMTP id 98e67ed59e1d1-37ffdc718f8so871708a91.0 for ; Mon, 29 Jun 2026 16:37:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1782776220; x=1783381020; 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=N6pm06jMuAnUZK3aucqd835Q1pNIgIV+VS/Zz9sIF38=; b=JqoWmOVMY/gVZJMh7AVXGJ3Uua49E3wVfKKt4ezsRK4oIjj18zgI+Y2ffrZyo5ObOV rbBTttafPbbqZ2OHHBn8VNYI/V/qk86e0PQXTGq8lfRepWfgML5EfUJlukCMM33GyNFZ d4aC9Ll0dFt6O4eJNMPC6InaGXsIj1aRJckDvNHBjinwp+WffFCVUT0C/5ShBOTf/7Qq NQVCWb1+es8EnIlJcgLUyNtEW5Xs3h2RAqQ0Y6UnyCMNCaq3KrV8ERSSDjLfdTgFr+kv gDipr7cldoA4R+leNx6rvOcYxlij/znnnyvQPk3yY/nfjRhGIl5EIVd1Uvdks2kqWtKL wFGQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1782776220; x=1783381020; 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=N6pm06jMuAnUZK3aucqd835Q1pNIgIV+VS/Zz9sIF38=; b=ROVl4Acy6zHGHukP4PB7r7b2RPB2EekBGgzZV7hwXgxhMlsbN8kbz8mCYK4b8voqI5 ZYMsPkST1MK53Yve0xo76fYy+qMHUPEWrs32g1wQ2idOHdt4kh0gXXr76DGMvVJ+FDQV 7jk1sY/fuUlLv/GWaX/j99QQEaukl/TFdFcRGZyPqEHYMZqBRhlyNvscc/C/ziQvq/g2 edpDyMmggvVKinl33XPyJ3F2eK0YZLIzuoNCtbW6UeBjROPASrDXQ9p26SURgauKeW2o 4NGwvER9cAljvVuVD61NpcjJmnkwFu3g9qXI1cqmrIp9iCifi90+UwgBdPzx6iwB/YJD f+dA== X-Gm-Message-State: AOJu0Yz1MsLS4keb4yglrZSQkvvML6u5LpQe9Oimcoku4Ns3Pbmttsrl e9McSjFAjWh8KWP4HWESMPq799yoRF6W3Czrfhwv9BWYQRGrCRIQT8g4XjSHqg== X-Gm-Gg: AfdE7clDfhnRUxeuEAF6Y0r/vTPhzzwqruc09gJrCD9wQY5VT5+NwMEDvQnzKKj4J3V o6Ng25a0LS9rYnpWZ6UPWtse4PsxsjOLR09H3OoVZL3EfAGMYYOJyEN3nerVUdGurgrkfuMgwxL FriaLe/YQZ/u5LMo4pmaCble+MXWldYbKUU8k3cPFV2cwG7etNvQOsAzQ7HP91wkAf4brOVgond IoRa3bZhDHFmGcWQxihhc7IWYAjXdmzD5gyL+0EiW4Y/Ark4cxD+u/IPJpbnvKp56tyCVC1Ti4Z saCWNRgALkdR8wYVW4GyXOKjYEEHbFQ8PuCrJtKANL5EyWTCLEY/gzCxuR1fi6ZnoPN1aYSR8cI 2+BM4yiGxQN+Hzv8B4gE61RFf2PNatnXDvi5yU80PFi7HUn9eEcSCrW+blCIGahPifmjPoy4Rwv V9EzaRn8GZLdspRDHHkkvYrVR1rmk2IsEpwy8L+7DrRXsW3B9eUBBCH/0yf78H1JdX6lU= X-Received: by 2002:a17:90b:4b88:b0:37e:90c8:53ea with SMTP id 98e67ed59e1d1-3805255a98cmr964805a91.10.1782776219930; Mon, 29 Jun 2026 16:36:59 -0700 (PDT) Received: from deepanshu-kernel-hacker.. ([2405:201:682f:383f:a844:5ab6:40a:9d25]) by smtp.gmail.com with ESMTPSA id 98e67ed59e1d1-380532d4563sm482117a91.6.2026.06.29.16.36.56 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 29 Jun 2026 16:36:59 -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 v2] locking/lockdep: skip irq save/restore in hardirq context in lock_release() Date: Tue, 30 Jun 2026 05:06:50 +0530 Message-ID: <20260629233650.90279-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. Fix this by conditionally skipping the irq save/restore when called from hardirq context, rather than duplicating the validation code in a separate path. Reported-by: syzbot+0635dc2e2c3c21a6aa04@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=0635dc2e2c3c21a6aa04 Signed-off-by: Deepanshu Kartikey --- Changes in v2: - Remove lockdep_hardirq() helper and recursion check as suggested by Longman - we only need to know if we are in hardirq context - Avoid code duplication by conditionally guarding irq save/restore with in_hardirq() check instead of duplicating the validation path --- kernel/locking/lockdep.c | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/kernel/locking/lockdep.c b/kernel/locking/lockdep.c index 2d4c5bab5af8..1ee69335d4ae 100644 --- a/kernel/locking/lockdep.c +++ b/kernel/locking/lockdep.c @@ -5882,14 +5882,17 @@ void lock_release(struct lockdep_map *lock, unsigned long ip) lock->key == &__lockdep_no_track__)) return; - raw_local_irq_save(flags); - check_flags(flags); + if (!in_hardirq()) { + raw_local_irq_save(flags); + check_flags(flags); + } lockdep_recursion_inc(); if (__lock_release(lock, ip)) check_chain_key(current); lockdep_recursion_finish(); - raw_local_irq_restore(flags); + if (!in_hardirq()) + raw_local_irq_restore(flags); } EXPORT_SYMBOL_GPL(lock_release); -- 2.43.0