linux-kernel - Re: 6.12-rc1: Lockdep regression bissected (virtio-net/console/scheduler)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20241003153231.GV5594@noisy.programming.kicks-ass.net>
Date: Thu, 3 Oct 2024 17:32:31 +0200
From: Peter Zijlstra <peterz@...radead.org>
To: Breno Leitao <leitao@...ian.org>
Cc: gregkh@...uxfoundation.org, pmladek@...e.com, mst@...hat.com,
	jasowang@...hat.com, xuanzhuo@...ux.alibaba.com, kuba@...nel.org,
	virtualization@...ts.linux.dev, netdev@...r.kernel.org,
	linux-kernel@...r.kernel.org, vschneid@...hat.com, axboe@...nel.dk
Subject: Re: 6.12-rc1: Lockdep regression bissected
 (virtio-net/console/scheduler)

On Thu, Oct 03, 2024 at 07:51:20AM -0700, Breno Leitao wrote:
> Upstream kernel (6.12-rc1) has a new lockdep splat, that I am sharing to
> get more visibility:
> 
> 	WARNING: HARDIRQ-safe -> HARDIRQ-unsafe lock order detected
> 
> This is happening because the HARDIRQ-irq-unsafe "_xmit_ETHER#2" lock is
> acquired in virtnet_poll_tx() while holding the HARDIRQ-irq-safe, and
> lockdep doesn't like it much.
> 
> I've bisected the problem, and weirdly enough, this problem started to
> show up after a unrelated(?) change in the scheduler:
> 
> 	52e11f6df293e816a ("sched/fair: Implement delayed dequeue")
> 
> At this time, I have the impression that the commit above exposed the
> problem that was there already.
> 
> Here is the full log, based on commit 7ec462100ef91 ("Merge tag
> 'pull-work.unaligned' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs")

This looks like the normal lockdep splat you get when the scheduler does
printk. I suspect you tripped a WARN, but since you only provided the
lockdep output and not the whole log, I cannot tell.

There is a fix in:

  git://git.kernel.org/pub/scm/linux/kernel/git/peterz/queue.git sched/urgent

that might, or might not help. I can't tell.