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

From: Avi Kivity
Date: Thu Apr 01 2010 - 12:41:10 EST

On 04/01/2010 06:36 PM, Andrea Arcangeli wrote:
On Thu, Apr 01, 2010 at 01:16:32PM +0200, Peter Zijlstra wrote:
On Thu, 2010-04-01 at 14:13 +0300, Avi Kivity wrote:

If someone is willing to audit all code paths to make sure these locks
are always taken in schedulable context I agree that's a better fix.
They had better be, they're not irq-safe. Also that's what lockdep is
In my original patchset I included patches from Christoph to convert
those locks to mutexes, there was apparently no problem at all with
that. But frankly I think the only problem here is the warning. The
only compliant we ever had here is from developers, no users at
all. If this was a practical problem I think we should have heard
something by now with so many KVM users out there (and gru too).

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).

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