Re: [PATCH] KVM: MMU: Fix rmap_remove() race

[Andrea Arcangeli <andrea@qumranet.com>]

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