From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-oi1-f198.google.com (mail-oi1-f198.google.com [209.85.167.198]) (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 BBDC1199D8 for ; Mon, 29 Jun 2026 00:50:32 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.167.198 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782694234; cv=none; b=KMz8G+nTlwUoAHdZLg9oUXr5Ebvih4W1V8r/n9yLGPBu1y+c94dzuGTRAPTiugMX0C12bKpY0So8P3wSe0lf3WT+qU+v4iR58k2Fv7PnpY14mowdjoIixsO91XiER2/n2mo6Z+9ZMJWEuOqdJMSg1LtJXtxLdxmr7Kw6M21RE+E= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782694234; c=relaxed/simple; bh=fTMZq94i1JAm9D+AxziOyFl6dflt1oRRCvurYj2SY5U=; h=MIME-Version:Date:In-Reply-To:Message-ID:Subject:From:To: Content-Type; b=WBVNZPu1puWACwDL9yZBNGAbO+g0aOeHWH+4g/vmwklEKH7XS5b4IU3jQkNds0ZLA8lGwfMxW+DhlTZbDnKPlwnuKG3BoH2NOvlJht+nTag0g4ucSsCHk6AC1RqnIkFVsFNnLuWQ63Mj4wmi0rJD21BRbf7RXQvJme2PUfb38Kw= 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.198 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-f198.google.com with SMTP id 5614622812f47-494d3abf6b4so3298900b6e.2 for ; Sun, 28 Jun 2026 17:50:32 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1782694232; x=1783299032; 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=ZXgs3ldtuN7f/LTsySnsghjgKhvZc5RsuyHbo+JLY2M1dmiGcCxmNTa4hAdLzvC92S tibYysQgCAzd0LFiXHdjjcu2SggcE1lr6QuYpc0ynoRUwVkboMRKANvFwYzo9s8k1XV6 8A0w8rmKq4mT8co8fUx4czvb3fQGZxgX91mHg3XzACGa8ec/vszm0l4yI0+gUT0tDrhw cS5EPm3WfkwNt9vKE+atXxsY6rGdBgUOybDgiNSUrJkrpwO7GtOn1ZQOk4wbEDl55aUq vTxdrvi8WoUXNHVKMMRmdahp8fwb2pF/mKuNB/No6DFktE7pYYKIDUnmX4N4LR3R4eYW w/5Q== X-Gm-Message-State: AOJu0Ywh1BpQcZrBtR9cunZh4S7C16GOAOPX7hDNcwvpr+LQ2VD7zXYB +/lldLpE/UT9t9o7JZOAy5tf5a2Cre6UMEhekfTGP92P07ewvtdVveoDuctozRUAtsgOig7gbtJ h2c6HjQtMKfyChZ8mshCxQAq3tvQnEkRC0AjfswanfzCzER8zx2SPprzEGSE= 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:d4f:b0:487:6930:d50 with SMTP id 5614622812f47-4943dfe1b47mr7180296b6e.35.1782694231905; Sun, 28 Jun 2026 17:50:31 -0700 (PDT) Date: Sun, 28 Jun 2026 17:50:31 -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: <6a41c157.9dc7bc9d.3393b4.0002.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