Problem With XFS + KVM

Chaitanya Kulkarni Chaitanya.Kulkarni at wdc.com
Thu Mar 4 23:32:35 GMT 2021


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 at fromorbit.com

Thanks a lot for the response Dave, that is what I thought, just wasn't
sure.





More information about the Linux-nvme mailing list