linux-kernel - Re: [syzbot] [kvm?] WARNING: locking bug in kvm_xen_set_evtchn

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: <20241126150331.E3qHY1JP@linutronix.de>
Date: Tue, 26 Nov 2024 16:03:31 +0100
From: Sebastian Andrzej Siewior <bigeasy@...utronix.de>
To: David Woodhouse <dwmw2@...radead.org>
Cc: syzbot <syzbot+919877893c9d28162dc2@...kaller.appspotmail.com>,
	boqun.feng@...il.com, bp@...en8.de, dave.hansen@...ux.intel.com,
	hdanton@...a.com, hpa@...or.com, kvm@...r.kernel.org,
	linux-kernel@...r.kernel.org, longman@...hat.com, mingo@...hat.com,
	paul@....org, pbonzini@...hat.com, seanjc@...gle.com,
	syzkaller-bugs@...glegroups.com, tglx@...utronix.de, x86@...nel.org
Subject: Re: [syzbot] [kvm?] WARNING: locking bug in kvm_xen_set_evtchn_fast

On 2024-11-26 14:49:40 [+0000], David Woodhouse wrote:
> On Tue, 2024-11-26 at 06:24 -0800, syzbot wrote:
> > syzbot has bisected this issue to:
> > 
> > commit 560af5dc839eef08a273908f390cfefefb82aa04
> > Author: Sebastian Andrzej Siewior <bigeasy@...utronix.de>
> > Date:   Wed Oct 9 15:45:03 2024 +0000
> > 
> >     lockdep: Enable PROVE_RAW_LOCK_NESTING with PROVE_LOCKING.
> 
> That's not it; this has always been broken with PREEMPT_RT I think.
> There was an attempt to fix it in
> https://lore.kernel.org/all/20240227115648.3104-8-dwmw2@infradead.org/
> 
> I'll dust that off and try again.

Oh thank you. The timer has been made to always expire in hardirq due to
HRTIMER_MODE_ABS_HARD, this is why you see the splat. If the hardirq
invocation is needed/ possible then the callback needs to be updated.

The linked patch has this hunk:
|-	read_lock_irqsave(&gpc->lock, flags);
|+	local_irq_save(flags);
|+	if (!read_trylock(&gpc->lock)) {
…
|+		if (in_interrupt())
|+			goto out;
|+
|+		read_lock(&gpc->lock);

This does not work. If interrupts are disabled (due to local_irq_save())
then read_lock() must not be used. in_interrupt() does not matter.

Side note: Using HRTIMER_MODE_ABS would avoid the splat at the cost that
on PREEMPT_RT the timer will be invoked in softirq context (as with
HRTIMER_MODE_ABS_SOFT on !PREEMPT_RT). There is no changed behaviour on
!PREEMPT_RT.

Sebastian