Re: port-xen/47057: Xen NetBSD DomU file system trash under Linux Dom0

[Manuel Bouyer <bouyer%antioche.eu.org@localhost>]

On Fri, Oct 12, 2012 at 05:52:22PM +0200, Roger Pau Monné wrote:
> I'm not sure, but I think we might have a problem when we call
> intr_biglock_wrapper, this function takes the kernel_lock, but just
> before calling it we call sti(), which allows further hypervisor
> callbacks. Isn't it posible that another hypervisor callback
> interrupts the execution of the handler, leaving the kernel_lock held
> and thus locking the system when this new callback tries to execute a
> handler?

Either the new callback wants to execute a MPSAFE handler and things will
run fine, or it will also try to grab the kernel_lock, and will either
succeed or be delayed depending on who did take the kernel_lock before.

Remember that kernel_lock is not a simple mutex, it's reentrant on
the same processor. So we may have one handler interrupted and the
new callback can grab the kernel_lock, because it's already owned
by its CPU. but then handlers reentrancy is protected by the traditional
spl mechanism.

-- 
Manuel Bouyer <bouyer%antioche.eu.org@localhost>
     NetBSD: 26 ans d'experience feront toujours la difference
--