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.
