Re: Problem With XFS + KVM

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.






[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]

  Powered by Linux