From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-oi1-f199.google.com (mail-oi1-f199.google.com [209.85.167.199]) (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 D049B40D585 for ; Mon, 29 Jun 2026 00:19:55 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.167.199 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782692397; cv=none; b=FqUHNqy6ZId5CQkJpsLKsgCxlUjeXI+sSs9+4Qd/BEZtrKyhHORsV45SjKOzCNVsWxuiUyBRsxmi+0NI19MqIEdjYFEX/PJpWawn+7nC3Tcrf7Qslo69TCSZNpUQFkO9w8eCdyS2ygA9S5s4vHYhaYvUTY7RJkdIbQ9CcnmhaoA= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782692397; c=relaxed/simple; bh=fTMZq94i1JAm9D+AxziOyFl6dflt1oRRCvurYj2SY5U=; h=MIME-Version:Date:In-Reply-To:Message-ID:Subject:From:To: Content-Type; b=Eey9empDer7OWhFPLRlbYui+eFPDTBfHa9ffawIpvpbZfjN4zCLsuxMnPV61Nkauoaeyb8ixmfpkvPankw94ZrxSl54dbUVn/GAOIz9y/cENs9NdUDnnqRstH7JmAfD/hrwbdt89Okr9a2E68EFD+75eCgC+PIcn38te3gX6yyU= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=fail (p=none dis=none) header.from=syzkaller.appspotmail.com; spf=pass smtp.mailfrom=M3KW2WVRGUFZ5GODRSRYTGD7.apphosting.bounces.google.com; arc=none smtp.client-ip=209.85.167.199 Authentication-Results: smtp.subspace.kernel.org; dmarc=fail (p=none dis=none) header.from=syzkaller.appspotmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=M3KW2WVRGUFZ5GODRSRYTGD7.apphosting.bounces.google.com Received: by mail-oi1-f199.google.com with SMTP id 5614622812f47-48f680bda84so4571152b6e.1 for ; Sun, 28 Jun 2026 17:19:55 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1782692395; x=1783297195; h=to:from:subject:message-id:in-reply-to:date:mime-version :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=bfEyjbpqZ4uk8aOZyrj/Sp2/h0AEKXfkNF9tg3a0MoA=; b=s3wkXsNI0x5diW19kZAC9OXwrGdW0iHvthqESM5mT95V9rHgqiwnnmAJ6z4G91+kY2 QrGH546DcipfOEShxpOlT97OYHymX95lAC7MA66nYOwLd1C9W7IsoT8rEffTwHlLmFw6 8iRsG5sfh6W/KLXTOIVlGf8W19ZFeTO7PReQn3P5EJkFstKa5PO7Q4bXBWBLZ5S/yOFr j2ioMjV1nGr3abcSmz4pFw2nkGI8iajA/87rMSQ8u/rtCVro2sZz+JzGcZG5yAthlzVq Z63I28dv/7qFa4s23B1c9yvBfwyd+6+G486xmU3J/7u9zxucESrciecX9tCWx+4xeRiP rEZg== X-Gm-Message-State: AOJu0YwaSmOLWlWHYo/tNQHBuZE18oXRQNl91JZffxFAcGrS6d2/1RMD oBvKaQefA6/zNsfiUJRGETl7NS3kPx1EwkJdAYEB2xF4CXS+G8Kr2QBw3iE4giTGUrqleDcdjqY zXoFVUrgzDz6M7r6FCdsuQsc6wT3bOrWSXEqdbsXIhBCjiux/thRN3pLADfA= Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-Received: by 2002:a05:6808:c1b3:b0:490:d1cb:af47 with SMTP id 5614622812f47-49217721987mr13014595b6e.25.1782692394837; Sun, 28 Jun 2026 17:19:54 -0700 (PDT) Date: Sun, 28 Jun 2026 17:19:54 -0700 In-Reply-To: <6a360fdf.871e809a.2d6dda.0001.GAE@google.com> X-Google-Appengine-App-Id: s~syzkaller X-Google-Appengine-App-Id-Alias: syzkaller Message-ID: <6a41ba2a.9dc7bc9d.3393b4.0001.GAE@google.com> Subject: Forwarded: [PATCH] locking/lockdep: skip irq save/restore in hardirq context in lock_release() From: syzbot To: linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com Content-Type: text/plain; charset="UTF-8" For archival purposes, forwarding an incoming command email to linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com. *** Subject: [PATCH] locking/lockdep: skip irq save/restore in hardirq context in lock_release() Author: kartikey406@gmail.com #syz test: git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next.git master 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. Link: https://syzkaller.appspot.com/bug?extid=0635dc2e2c3c21a6aa04 Reported-by: syzbot+0635dc2e2c3c21a6aa04@syzkaller.appspotmail.com 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