From: Sean Christopherson <seanjc@google.com>
To: Chaitanya Kulkarni <Chaitanya.Kulkarni@wdc.com>
Cc: Dave Chinner <david@fromorbit.com>,
"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
"linux-xfs@vger.kernel.org" <linux-xfs@vger.kernel.org>,
"linux-nvme@lists.infradead.org" <linux-nvme@lists.infradead.org>
Subject: Re: Problem With XFS + KVM
Date: Thu, 4 Mar 2021 15:51:42 -0800 [thread overview]
Message-ID: <YEFyjtsftfU2WRPg@google.com> (raw)
In-Reply-To: <BYAPR04MB49657CB2E5F0C2F2FC4F24E686979@BYAPR04MB4965.namprd04.prod.outlook.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
_______________________________________________
Linux-nvme mailing list
Linux-nvme@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-nvme
WARNING: multiple messages have this Message-ID (diff)
From: Sean Christopherson <seanjc@google.com>
To: Chaitanya Kulkarni <Chaitanya.Kulkarni@wdc.com>
Cc: Dave Chinner <david@fromorbit.com>,
"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
"linux-xfs@vger.kernel.org" <linux-xfs@vger.kernel.org>,
"linux-nvme@lists.infradead.org" <linux-nvme@lists.infradead.org>
Subject: Re: Problem With XFS + KVM
Date: Thu, 4 Mar 2021 15:51:42 -0800 [thread overview]
Message-ID: <YEFyjtsftfU2WRPg@google.com> (raw)
In-Reply-To: <BYAPR04MB49657CB2E5F0C2F2FC4F24E686979@BYAPR04MB4965.namprd04.prod.outlook.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
next prev parent reply other threads:[~2021-03-04 23:52 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-04 22:34 Problem With XFS + KVM Chaitanya Kulkarni
2021-03-04 22:34 ` Chaitanya Kulkarni
2021-03-04 23:13 ` Dave Chinner
2021-03-04 23:13 ` Dave Chinner
2021-03-04 23:32 ` Chaitanya Kulkarni
2021-03-04 23:32 ` Chaitanya Kulkarni
2021-03-04 23:51 ` Sean Christopherson [this message]
2021-03-04 23:51 ` Sean Christopherson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=YEFyjtsftfU2WRPg@google.com \
--to=seanjc@google.com \
--cc=Chaitanya.Kulkarni@wdc.com \
--cc=david@fromorbit.com \
--cc=kvm@vger.kernel.org \
--cc=linux-nvme@lists.infradead.org \
--cc=linux-xfs@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.