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

From: Avi Kivity
Date: Thu Apr 01 2010 - 07:13:39 EST

On 04/01/2010 02:04 PM, Thomas Gleixner wrote:

mmu_take_all_locks() takes a spinlock for each vma, which means we increase
the preempt count by the number of vmas in an address space. Since the user
controls the number of vmas, they can cause preempt_count to overflow.

Fix by making mmu_take_all_locks() only disable preemption once by making
the spinlocks preempt-neutral.
Right, so while this will get rid of the warning it doesn't make the
code any nicer, its still a massive !preempt latency spot.
I'm not sure whether this is a real well done April 1st joke or if there
is someone trying to secure the "bad taste patch of the month" price.

I don't think a spin_lock_nested_while_preempt_disabled() is worthwhile for this.

Anyway, I don't see a reason why we can't convert those locks to
mutexes and get rid of the whole preempt disabled region.

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.

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