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

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

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?