Re: Reauthentication EINTR bug

[Carl Fredrik Hammar]

On Mon, Jul 05, 2010 at 01:23:15PM -0700, Roland McGrath wrote:
> > This would be ideal, but my current understanding is that
> > interrupt_operation() is mostly advisory and that the operation will
> > restart or return EINTR regardless of what the server does, and if this
> > is true then it is impossible to complete the RPC.  However, my view of
> > the interruption code is not consistent enough for me to be certain so
> > I will investigate this possibility further.
> 
> I don't understand what you mean.  There is a timeout of 1 second
> (_hurdsig_interrupt_timeout) for pathologically broken servers that don't
> reply to interrupt_operation.  There is a timeout of 3 seconds
> (_hurd_interrupted_rpc_timeout) for pathologically broken servers that
> don't reply to operations in progress after an interrupt_operation RPC.
> Those are failsafes for broken servers.  It is certainly not the case that
> interrupt_operation is "mostly advisory".  All servers are obliged to reply
> quickly to interrupt_operation and to make affected RPCs reply quickly.

Thanks for clearing this up for me.

This means there's a bug in the code that send the interruption, or auth
is pathologically broken.  It could be that interrupt_operation originates
from hurd_thread_cancel, which ignores reply port location returned
by _hurdsig_abort_rpcs.  This is why I thought interrupt_operation()
was only advisory, but this is actually a bug, right?  I will try to
confirm whether hurd_thread_cancel is the culprit when I have more time.

Still, I'm not too sure about assuming the timeout never happens for auth,
since the client will either hang or fail with EPERM and won't know
what has happend.  I haven't yet ruled out that timeouts are causing
the bug.  Perhaps we should atleast return a real error instead of
EINTR if interrupt_operation fails, if this indeed means the server is
pathologically broken.

Regards,
  Fredrik