From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [PATCH] KVM: MMU: Fix rmap_remove() race Date: Thu, 27 Mar 2008 15:56:56 +0200 Message-ID: <47EBA7A8.2020804@qumranet.com> References: <1206543773-26386-1-git-send-email-avi@qumranet.com> <20080326192231.GC11130@v2.random> <20080326192746.GD11130@v2.random> <47EB56BE.9000909@qumranet.com> <20080327135256.GB13959@duo.random> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: kvm-devel@lists.sourceforge.net, Marcelo Tosatti To: Andrea Arcangeli Return-path: In-Reply-To: <20080327135256.GB13959@duo.random> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kvm-devel-bounces@lists.sourceforge.net Errors-To: kvm-devel-bounces@lists.sourceforge.net List-Id: kvm.vger.kernel.org Andrea Arcangeli wrote: > On Thu, Mar 27, 2008 at 10:11:42AM +0200, Avi Kivity wrote: > >> Erm I don't think this means what you think it means. This is the >> kernel/user communication area, used to pass exit data to userspace. It's >> not the memslot vma. >> > > Yep... only the kvm_vm_vm_ops can run gfn_to_page, and I assume that > was used by the old userland and not relevant anymore (smaps don't > show it either), or the pages could not be unmapped. So btw, that > kvm-vm anon inode must be disabled when mmu notifiers are configured > in to guarantee that access to /dev/kvm won't lead to mlock behavior. > That's not good. We need to support the older userspace, for a while yet. Why is there a problem? IIRC it's just anonymous memory. -- error compiling committee.c: too many arguments to function ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace