From: Christoffer Dall <cdall@linaro.org>
To: Andrea Arcangeli <aarcange@redhat.com>
Cc: Suzuki K Poulose <Suzuki.Poulose@arm.com>,
Alexander Graf <agraf@suse.de>,
"kvmarm@lists.cs.columbia.edu" <kvmarm@lists.cs.columbia.edu>,
"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Stable <stable@vger.kernel.org>
Subject: Re: [PATCH v2] KVM: arm/arm64: Handle hva aging while destroying the vm
Date: Mon, 17 Jul 2017 20:23:31 +0200 [thread overview]
Message-ID: <20170717182331.GA14069@cbox> (raw)
In-Reply-To: <20170717151617.GC6344@redhat.com>
On Mon, Jul 17, 2017 at 05:16:17PM +0200, Andrea Arcangeli wrote:
> On Mon, Jul 17, 2017 at 04:45:10PM +0200, Christoffer Dall wrote:
> > I would also very much like to get to the bottom of this, and at the
> > very least try to get a valid explanation as to how a thread can be
> > *running* for a process where there are zero references to the struct
> > mm?
>
> A thread shouldn't be possibly be running if mm->mm_users is zero.
>
ok, good, then I don't have to re-take OS 101.
> > I guess I am asking where this mmput() can happen for a perfectly
> > running thread, which hasn't processes signals or exited itself yet.
>
> mmput runs during exit(), after that point the vcpu can't run the KVM
> ioctl anymore.
>
also very comforting that we agree on this.
> > The dump you reference above seems to indicate that it's happening
> > under memory pressure and trying to unmap memory from the VM to
> > allocate memory to the VM, but all seems to be happening within a VCPU
> > thread, or am I reading this wrong?
>
> In the oops the pgd was none while KVM vcpu ioctl was running, the
> most likely explanation is there were two VM running in parallel in
> the host, and the other one was quitting (mm_count of the other VM was
> zero, while mm_count of the VM that oopsed within the vcpu ioctl was >
> 0). The oops information itself can't tell if there was one or two VM
> running in the host so > 1 VM running is the most plausible
> explanation that doesn't break the above in invariants.
That's very keenly observed, and a really good explanation.
> It'd be nice
> if Alexander can confirm it, if he remembers about that specific setup
> after a couple of months since it happened.
My guess is that this was observed on the suse build machines with
arm64, and Alex ususally explains that these machines run *lots* of VMs
at the same time, so this sounds very likely.
Alex, can you confirm this was the type of workload?
>
> Even if there was just one VM running in the host, it would more
> likely mean something inside KVM ARM code is clearing the pgd before
> mm_users reaches zero, i.e. before the last mmput.
I don't think we have this.
>
> It's very unlikely mm_users could have been > 0 while the vcpu thread
> was running as many more things would fall apart in such case, not
> just the needed pgd check during mmu notifier post process exit.
>
That was my rationale exactly. Thanks for confirming!
-Christoffer
next prev parent reply other threads:[~2017-07-17 18:23 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-07-05 6:20 [PATCH v2] KVM: arm/arm64: Handle hva aging while destroying the vm Alexander Graf
2017-07-05 6:20 ` Alexander Graf
2017-07-05 6:27 ` Christoffer Dall
2017-07-05 8:57 ` Suzuki K Poulose
2017-07-05 8:57 ` Suzuki K Poulose
2017-07-06 7:07 ` Alexander Graf
2017-07-06 7:45 ` Christoffer Dall
2017-07-06 9:31 ` Andrea Arcangeli
2017-07-06 9:43 ` Christoffer Dall
2017-07-06 9:34 ` Suzuki K Poulose
2017-07-06 9:34 ` Suzuki K Poulose
2017-07-06 9:42 ` Christoffer Dall
2017-07-14 16:40 ` Suzuki K Poulose
2017-07-16 19:56 ` Christoffer Dall
2017-07-17 13:03 ` Suzuki K Poulose
2017-07-17 14:45 ` Christoffer Dall
2017-07-17 15:16 ` Andrea Arcangeli
2017-07-17 15:16 ` Andrea Arcangeli
2017-07-17 18:23 ` Christoffer Dall [this message]
2017-07-17 20:49 ` Alexander Graf
2017-07-17 20:49 ` Alexander Graf
2017-07-06 8:14 ` Christoffer Dall
2017-07-06 8:14 ` Christoffer Dall
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=20170717182331.GA14069@cbox \
--to=cdall@linaro.org \
--cc=Suzuki.Poulose@arm.com \
--cc=aarcange@redhat.com \
--cc=agraf@suse.de \
--cc=kvm@vger.kernel.org \
--cc=kvmarm@lists.cs.columbia.edu \
--cc=linux-kernel@vger.kernel.org \
--cc=stable@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.