On Thu, 3 Apr 2008, Andrea Arcangeli wrote: > My attempt to fix this once and for all is to walk all vmas of the > "mm" inside mmu_notifier_register and take all anon_vma locks and > i_mmap_locks in virtual address order in a row. It's ok to take those > inside the mmap_sem. Supposedly if anybody will ever take a double > lock it'll do in order too. Then I can dump all the other locking and
What about concurrent mmu_notifier registrations from two mm_structs that have shared mappings? Isnt there a potential deadlock situation? > faults). So it should be ok to take all those locks inside the > mmap_sem and implement a lock_vm(mm) unlock_vm(mm). I'll think more > about this hammer approach while I try to implement it... Well good luck. Hopefully we will get to something that works. ------------------------------------------------------------------------- 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 _______________________________________________ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
