From: Paolo Bonzini <pbonzini@redhat.com>
To: peng.hao2@zte.com.cn
Cc: rkrcmar@redhat.com, x86@kernel.org, kvm@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] KVM: X86: clear page flags when freeing kvm mmapping page
Date: Tue, 10 Oct 2017 18:10:39 +0200 [thread overview]
Message-ID: <52cce003-6e78-477d-912d-2308ddd05d2a@redhat.com> (raw)
In-Reply-To: <201710102339451604418@zte.com.cn>
On 10/10/2017 17:39, peng.hao2@zte.com.cn wrote:
>>How did you know that this was a kvm_run page, and why is it the right
>>thing to clear the flags?
>
> first I can't repeat this "bad page report". But I add print message to
> trace. I found that kvm_run page is freed with page flags
> PG_dirty and PG_referenced. I don't think it is right status for
> freed page.
That would be the symptom, not the cause. So it would not be the right
thing to clear the flags.
> second, kvm_run page is mmaped in qemu with fd of "kvm-vcpu". It has
> special mmap function(kvm_vcpu_mmap),but when munmap is called
> the kvm_run page goes into general munmap route.it is not suitable for
> kvm_run page that is set dirty in munmap route.
There are many many cases where .mmap and .fault are defined but .munmap
isn't, and none of them calls ClearPageDirty or ClearPageReferenced; see
for example kernel/relay.c (whose only user is blktrace).
Can the page be dirty in those cases? If not, what makes KVM different?
Since you cannot reproduce the failure, this patch is basically
untested. You need to dig deeper into what's happening, and provide a
better justification for what you are doing. But generally, it's a bad
sign if you're doing something special that no other device in the
kernel is doing.
Paolo
next parent reply other threads:[~2017-10-10 16:10 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <201710102339451604418@zte.com.cn>
2017-10-10 16:10 ` Paolo Bonzini [this message]
2017-10-10 19:26 Peng Hao
2017-10-10 12:41 ` Paolo Bonzini
2017-10-11 0:56 ` Wanpeng Li
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=52cce003-6e78-477d-912d-2308ddd05d2a@redhat.com \
--to=pbonzini@redhat.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=peng.hao2@zte.com.cn \
--cc=rkrcmar@redhat.com \
--cc=x86@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®