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] [day] [month] [year] [list]

Message-ID: <e61a1f1c7209de3d5ce07abd3c102ff5ad82ac2d.camel@infradead.org>
Date: Tue, 26 Nov 2024 16:26:28 +0000
From: David Woodhouse <dwmw2@...radead.org>
To: Sebastian Andrzej Siewior <bigeasy@...utronix.de>
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 Tue, 2024-11-26 at 16:03 +0100, Sebastian Andrzej Siewior wrote:
> 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.


Right. At the end of that discussion, I think I concluded that if we
make it use read_trylock() and fall back to the slow path, then it
doesn't actually need to disable interrupts at all anyway.

> 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.

Ah, shiny. If that *only* pushes it to softirq context for PREEMPT_RT
and leaves it in hardirq context for everything else, I think that's a
good choice.

I'll have a quick look at eliminating the _irqsave completely though,
as it may be beenficial.

Download attachment "smime.p7s" of type "application/pkcs7-signature" (5965 bytes)