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@xxxxxxxxxxxxx
>
> 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@xxxxxxxxxxx
