Re: Problem With XFS + KVM

[Sean Christopherson <seanjc@google.com>]

On Thu, Mar 04, 2021, Chaitanya Kulkarni wrote:
> On 3/4/21 15:14, Dave Chinner wrote:
> >> 00000000003506e0
> >> [  587.766864] Call Trace:
> >> [  587.766867]  kvm_wait+0x8c/0x90
> >> [  587.766876]  __pv_queued_spin_lock_slowpath+0x265/0x2a0
> >> [  587.766893]  do_raw_spin_lock+0xb1/0xc0
> >> [  587.766898]  _raw_spin_lock+0x61/0x70
> >> [  587.766904]  xfs_extent_busy_trim+0x2f/0x200 [xfs]
> > That looks like a KVM or local_irq_save()/local_irq_restore problem.
> > kvm_wait() does:
> >
> > static void kvm_wait(u8 *ptr, u8 val)
> > {
> >         unsigned long flags;
> >
> >         if (in_nmi())
> >                 return;
> >
> >         local_irq_save(flags);
> >
> >         if (READ_ONCE(*ptr) != val)
> >                 goto out;
> >
> >         /*
> >          * halt until it's our turn and kicked. Note that we do safe halt
> >          * for irq enabled case to avoid hang when lock info is overwritten
> >          * in irq spinlock slowpath and no spurious interrupt occur to save us.
> >          */
> >         if (arch_irqs_disabled_flags(flags))
> >                 halt();
> >         else
> >                 safe_halt();
> >
> > out:
> >         local_irq_restore(flags);
> > }
> >
> > And the warning is coming from the local_irq_restore() call
> > indicating that interrupts are not disabled when they should be.
> > The interrupt state is being modified entirely within the kvm_wait()
> > code here, so none of the high level XFS code has any influence on
> > behaviour here.
> >
> > Cheers,
> >
> > Dave.
> > -- Dave Chinner david@fromorbit.com
> 
> Thanks a lot for the response Dave, that is what I thought, just wasn't
> sure.

Yep, Wanpeng posted a patch for this.

https://lkml.kernel.org/r/1614057902-23774-1-git-send-email-wanpengli@tencent.com