[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Reauthentication implementation flaw due to EINTR

From: Carl Fredrik Hammar
Subject: Re: Reauthentication implementation flaw due to EINTR
Date: Tue, 29 Dec 2009 22:48:26 +0100
User-agent: Mutt/1.5.20 (2009-06-14)


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...


reply via email to

[Prev in Thread] Current Thread [Next in Thread]