Re: Reauthentication implementation flaw due to EINTR

[Carl Fredrik Hammar]

On Sat, Dec 26, 2009 at 09:12:08PM +0100, Samuel Thibault wrote:
> I've checked again the result
> 
> Carl Fredrik Hammar, le Sat 26 Dec 2009 19:58:12 +0100, a écrit :
> > > There is this issue as well, which I have fixed already in commit
> > > 041baa80 (and indeed seen cases where it helped), but that's not enough,
> > > because not only auth gets EINTR here and can fix things, but ext2fs
> > > also gets an EINTR but can't able to restart the call in iohelp_reauth
> > > since the rendez-vous port is dead and thus gets EINVAL.
> > 
> > Why does this happen?
> 
> I don't know, but I know for sure that auth_server_authenticate returns
> EINTR in ext2fs (and next call returns EINVAL), even if auth never
> returned EINTR.

OK, I think I have a vague picture of what is going on:
ports_interrupt_self_on_port_death
ports_interrupt_self_on_notification
ports_interrupt_rpc_on_notification,
which requests notification (to the same port as
auth_server_authenticate).

When rendezvous port dies we get the notification:
ports_notify_server
ports_do_mach_notify_dead_name
ports_dead_name
ports_interrupt_notified_rpcs
hurd_thread_cancel (in glibc)
_hurdsig_abort_rpcs,
which does some funky stuff that seems to hijack any pending RPCs
to make them return EINTR.

If the notification request is canceled before auth_user_authenticate
returns there should be no problem.  I don't know how to do that, as
libports doesn't seem to have a function for it.  The primitive function
would be mach_port_request_notification with a null port, but I assume
there is other stuff to clean up.

Alternatively, the notification can be handled separately by the auth
server, perhaps by overriding libports's notify server.

Regards,
  Fredrik