Re: [COUNTERPATCH] mm: avoid overflowing preempt_count() in mmu_take_all_locks()

From: Avi Kivity
Date: Thu Apr 01 2010 - 12:03:55 EST

On 04/01/2010 06:54 PM, Andrea Arcangeli wrote:

The only single reason I'd go for mutexes would be to accommodate
XPMEM requirements once and for all, no other reason.

There is also a minor benefit for kvm. Reduced latency over large mmu
operations; code simplification (we now have some
copy_from_user_inatomic() that could be simplified).
Where exactly is KVM taking these locks?

Not these locks, but if we go all the way and make mmu notifiers sleepable, we can convert mmu_lock to a mutex.

KVM should only call into
GUP, and GUP itself won't iterate over rmaps either. GUP just walks
the host pagetables and trigger page faults if the pages aren't

We'll probably deadlock then, gup -> change_pte notifier -> mmu_lock. But we can probably work around it.

I don't see how you're going to remove
copy_from_user_inatomic() given we don't have vmas and other metadata
to take those locks. Maybe we can stop calling GUP but even if we take
the anon_vma mutex/semaphore I think it won't still prevent munmap to
drop the anon pages from under us (even if it'd stop the VM to unmap
them through rmap). To freeze the mapping one would need to take
mmap_sem in write mode in addition to the anon_vma mutex/sem which is
unlikely a win compared to just gup+copy_from_user_inatomic. So I
don't see immediate benefits for KVM but maybe I'm missing something
of course!

I meant replace c_f_u_inatomic() by c_f_u() (that's why the benefit is minor - we only simplify the failure path). Sorry for being unclear.

error compiling committee.c: too many arguments to function

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at