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

[Roger Pau Monné <royger%NetBSD.org@localhost>]

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

From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <royger%NetBSD.org@localhost>
To: Manuel Bouyer <bouyer%antioche.eu.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:55:56 +0200

 On Fri, Oct 12, 2012 at 6:10 PM, Manuel Bouyer 
<bouyer%antioche.eu.org@localhost> wrote:
 > 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.
 
 When you say it's protected by the same mechanism as normal handlers,
 I assume it's due to the code in evtchn.c, the "splx" section of
 evtchn_do_event, so there's no way for example that xbd_handler might
 be interrupted by another xbd_handler?