Bug#105476: proc and auth not robust

[Roland McGrath]

> There are two bugs here, in my opinion.  First, I think that proc should
> just loose the global lock while calling auth_server_authenticate (XXX have
> to check if this introduces any races).  

Agreed.  I see no reason it needs to hold the lock before the first line
that touches P->p_id.  Hmm, I wonder what happens if the process dies while
proc is blocked in auth_server_authenticate.  process_has_exited will have
come in and done ids_rele(p->p_id).  So it's necessary to check p_dead
after reacquiring the lock.  I've checked in a change to do this, which I
leave it to you to test and debug.  I made it return EAGAIN when p_dead has
become set during the block--in practice it should never be seen, since the
caller is always in the dead process.  That is at least an incremental
improvement and turns a potential for total wedge into just a potential for
leaks.

> This will occupy the current thread, though, and we must be careful not
> to make it wait for all eternity (see below). Alternatively, proc could
> make use of asynchronous communication (eg call
> auth_server_authentication_request and return MIG_NO_REPLY, then send the
> real answer later in S_auth_server_authenticate_reply).  Either will
> prevent proc from being stuck.

When long blocks are expected (like for io_select or blocking i/o calls),
then it consumes less memory and threads to use asynchronous RPC.  But
let's assume that the common case is a very quick RPC to the auth server,
in which case it's more efficient to let the thread block.  (In the ideal
case, there are no wasted context switches.)  Then we need only consider
the pathological cases, and those don't need to be efficient, just not leak.

> The other issue is that even if we do this, both auth and proc will sit
> on memory and threads if the user destroys the rendezvous port.  I think
> that auth should request a dead name notification for the rendezvous
> port, and on getting such a notification, go ahead and signal the
> associated condition.  The sleepers should check if the rendezvous port
> was destroyed and return with an appropriate error message.  This
> prevents the auth server and the server with a pending authentification
> from leaking any resources.

It looks to me like that is already handled.
Note `ports_interrupt_self_on_port_death', auth.c line 403 (and line 322).