Re: Reauthentication implementation flaw due to EINTR

[Carl Fredrik Hammar]

Hi,

On Mon, Dec 28, 2009 at 03:43:47AM +0100, Samuel Thibault wrote:
> Carl Fredrik Hammar, le Sun 27 Dec 2009 22:24:24 +0100, a écrit :
> > 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).
> 
> But in another task (auth vs ext2fs). That's where I've still not found
> what makes ext2fs return EINTR.
>
> > When rendezvous port dies we get the notification:
> 
> Here we seemingly see ext2fs get the notification, but why?
> 
> > 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.

I was hoping _hurdsig_abort_rpcs made auth_server_authenticate return
EINTR somehow by interrupting auth_server_authenticate_reply (using
thread_abort).  But studying the code further it seems only interrupt
the sending and not resend an EINTR message.  (The only problem I can
think of happening here is that the send isn't retried in which case
ext2fs would hang.)

So I looked further at libports which does a lot of bookkeeping of the
pending RPCs, and so should be able to hijack the them to return EINTR.
But none of the relevant code has any use of EINTR, so I don't think
that's it either.

It's still a mystery to me why ext2fs gets an EINTR without auth
explicitly returning EINTR...

Regards,
  Fredrik