From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrea Arcangeli Subject: Re: [PATCH] KVM: MMU: Fix rmap_remove() race Date: Mon, 31 Mar 2008 11:25:01 +0200 Message-ID: <20080331092500.GA10582@duo.random> References: <20080326192231.GC11130@v2.random> <20080326192746.GD11130@v2.random> <47EB56BE.9000909@qumranet.com> <20080327135256.GB13959@duo.random> <47EBA7A8.2020804@qumranet.com> <20080327142633.GC13959@duo.random> <47EBB0CB.8020703@qumranet.com> <20080327145025.GD13959@duo.random> <20080328140113.GA9215@duo.random> <47F08614.8080501@qumranet.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: kvm-devel@lists.sourceforge.net, Marcelo Tosatti To: Avi Kivity Return-path: Content-Disposition: inline In-Reply-To: <47F08614.8080501@qumranet.com> 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 On Mon, Mar 31, 2008 at 09:35:00AM +0300, Avi Kivity wrote: > This can be done by taking mmu_lock in _begin and releasing it in _end, > unless there's a lock dependency issue. The main problem is if want to be able to co-exit with XPMEM methods registered in the same notifier chain for the same MM with the KVM methods. The ideal would be to solve the race with a non-blocking lock like seqlock. > I don't understand your conclusion: you prove that mlock() is not good > enough, then post a patch to do it? mlock isn't good enough to allow munmap/madvise(don't need). So mlock fixes the race in the current kvm code, but only unless you use ballooning. This is because VM_LOCKED should be ignored by madvise(don't need). But at least this is only a trouble for smp guest. It'd require rmap_remove to run on a different physical cpu while another qemu thread runs madvise. So supposedly with an up guest, the guest won't run rmap_remove while madvise runs. To better explain the race, if we could take the mmu_lock around madvise that would fix it for smp guest too (however currently it's userland calling into madvise so that's not feasible with the current model). > I'll take another shot at fixing rmap_remove(), I don't like to cripple > swapping for 2.6.25 (though it will only be really dependable in .26). Ok! Clearly it would look more robust if rmap_remove is capable of doing the last free on the page and it won't relay on the page not to be freed until mmu_lock is released. ------------------------------------------------------------------------- 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