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

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

The following reply was made to PR port-xen/47057; it has been noted by GNATS.

From: Manuel Bouyer <bouyer%antioche.eu.org@localhost>
To: Roger Pau =?iso-8859-1?Q?Monn=E9?= <royger%NetBSD.org@localhost>
Cc: gnats-bugs%NetBSD.org@localhost, port-xen-maintainer%NetBSD.org@localhost,
        gnats-admin%NetBSD.org@localhost, netbsd-bugs%NetBSD.org@localhost
Subject: Re: port-xen/47057: Xen NetBSD DomU file system trash under Linux
 Dom0
Date: Fri, 12 Oct 2012 18:10:27 +0200

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