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
