From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932375AbdJJQKo (ORCPT ); Tue, 10 Oct 2017 12:10:44 -0400 Received: from mx1.redhat.com ([209.132.183.28]:48838 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932075AbdJJQKn (ORCPT ); Tue, 10 Oct 2017 12:10:43 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com D64173A26D Authentication-Results: ext-mx09.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx09.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=pbonzini@redhat.com Subject: Re: [PATCH] KVM: X86: clear page flags when freeing kvm mmapping page To: peng.hao2@zte.com.cn Cc: rkrcmar@redhat.com, x86@kernel.org, kvm@vger.kernel.org, linux-kernel@vger.kernel.org References: <201710102339451604418@zte.com.cn> From: Paolo Bonzini Message-ID: <52cce003-6e78-477d-912d-2308ddd05d2a@redhat.com> Date: Tue, 10 Oct 2017 18:10:39 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <201710102339451604418@zte.com.cn> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.38]); Tue, 10 Oct 2017 16:10:43 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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