On Sat, 2005-12-03 at 09:12 +0000, Keir Fraser wrote:
> On 2 Dec 2005, at 23:31, Rusty Russell wrote:
>
> >> It can change, between lines 340 and 341 (where we have no locks
> >> held).
> >
> > Hmm, you mean same domain makes another hypercall in parallel to close
> > the event channel then rebind it to a different domain?
>
> Yes. That would be very stupid of the guest, but Xen needs to protect
> itself.
>
> > In which case, close fails with EINVAL?
>
> I'm open to suggestions for a better error code.
Technically, they've asked it to be closed, so we should close it.
However, since they can't tell the difference between this case and the
case where we hit it in ECS_FREE, which would also return -EINVAL.
A comment could elucidate, perhaps?
Rusty.
Signed-off-by: Rusty Russell <rusty@xxxxxxxxxxxxxxx>
diff -r 4d4cb5e472af xen/common/event_channel.c
--- a/xen/common/event_channel.c Thu Dec 1 07:26:33 2005
+++ b/xen/common/event_channel.c Sun Dec 4 21:10:17 2005
@@ -344,6 +344,7 @@
}
else if ( d2 != chn1->u.interdomain.remote_dom )
{
+ /* current closed and rebound, between d1 unlock and d2 lock. */
rc = -EINVAL;
goto out;
}
--
A bad analogy is like a leaky screwdriver -- Richard Braakman
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|