bug-hurd
[Top][All Lists]
Advanced

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

Re: Reauthentication implementation flaw due to EINTR


From: Samuel Thibault
Subject: Re: Reauthentication implementation flaw due to EINTR
Date: Mon, 28 Dec 2009 11:25:36 +0100
User-agent: Mutt/1.5.12-2006-07-14

Samuel Thibault, le Mon 28 Dec 2009 11:14:04 +0100, a écrit :
> Da Zheng, le Mon 28 Dec 2009 17:59:55 +0800, a écrit :
> > On 09-12-28 上午3:56, Carl Fredrik Hammar wrote:
> > > 
> > > 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.
> > So the registered deadname notification can cancel the RPC (i.e,
> > auth_server_authenticate RPC is this case)? and the thread will somehow 
> > jump to
> > some place to return EINTR and doesn't execute hurd_condition_wait() and the
> > code below it?
> 
> It does, but that's not a problem in the case of auth now that I have
> patched it.

Err, no, I mean the RPC is interrupted and hurd_condition_wait returns 1
instead of 0, but that's not a problem etc.

Samuel




reply via email to

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