[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: port-xen/47057: Xen NetBSD DomU file system trash under Linux Dom0
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,
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
> 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?
Main Index |
Thread Index |