Re: Getting Started with Hurd-L4

[Marcus Brinkmann]

At Mon, 25 Oct 2004 23:06:48 +0100,
Neal H. Walfield wrote:
> 
> > However, this can only be done with server-side
> > support (the server must be informed about the cancelation - if we
> > simply abort the IPC without letting the server know, we are violating
> > the protocol and leave our client-server connection in an undefined
> > state.  The server would have no way to find out that we canceled it
> > without trying to send a reply, at which time the reply would get
> > lost, which is sometimes fatal for non-recoverable, non-repeatable
> > operations).
> 
> This should only hurt the client, not the server.  That is: if
> canceling an IPC would hurt the server there is an opportunity for an
> attack by malicious clients.  Right?

Yes, it would only hurt the client.  Actually, the server could
pro-actively protect against this by dropping the client connection if
a single reply message fails.  But even if it wouldn't, and the
resources would go stale, it would clean them up the time the client
dies.  This is the same case as if the client would just receive the
reply, and then do nothing with the data at all.

However, the point here is that if the client _wants_ to cooperate, it
must have a robust and fail-proof way to do so.  IOW: We need a
mechanism to cancel an RPC that a cooperative client can use to cancel
an RPC without risking to lose a reply from the server in a race
condition.  There doesn't seem to be primitive support for that in L4.
The only solution I found involves registering all pending RPCs in a
global datastructure, which may be an OK solution after all.

But I understand now Roland's comment a few years ago that cancelation
of RPCs should be supported by the primitive IPC mechanism.  It makes
a lot of sense, and also fits the "migrating thread" model of RPCs.
Ie, you want some simple way to signal the thread its cancelation,
even if the thread is currently - logically - migrated to the server
to perform the RPC operation.  For L4, I proposed two specific
additions to the IPC mechanism (atomic check-and-ipc, and thread can
receive while being halted), that I believe (so far) are sufficient
and necessary to implement cancellable IPC with only minimal overhead
(one bit in the UTCB for the cancel flag, and one thread-local
variable that can be read from other threads, that contains the
destination thread ID of the IPC operation) and no fuzz.

Thanks,
Marcus