On 10/10/2017 17:39, peng.hao2@xxxxxxxxxx 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
