Re: Reauthentication implementation flaw due to EINTR

[Samuel Thibault]

Da Zheng, le Mon 28 Dec 2009 19:43:11 +0800, a écrit :
> On 09-12-28 下午7:21, Samuel Thibault wrote:
> > Da Zheng, le Mon 28 Dec 2009 19:03:26 +0800, a écrit :
> >> Doesn't it mean the RPC on userauth (namely, auth_user_authenticate)
> >> is to be canceled?
> > 
> > No, here the auth_user_authenticate() RPC is over (else the initiator
> > wouldn't have destroyed the rendezvous port). 
> What do you mean by that? I was talking about which RPC will be canceled by 
> the
> deadname notification requested in the server side of 
> auth_server_authenticate.

Right, but auth_user_authenticate can't be canceled since it's finished
by the time the rendezvous port is destroyed.

> > Mmm, thinking again about it, while I said in a previous mail that
> > I tried and it failed, that was with the original version, not
> > with my patched version. In the original version, we do let the
> > auth_user_authenticate RPC return before hurd_condition_wait wakes in
> > the auth_server_authenticate RPC server, which will bring the interrupt.
> > 
> >> In this case, auth_server_authenticate RPC can never be interrupted
> >> by the deadname notification any more even if the rendezvous port is
> >> destroyed before auth_server_authenticate RPC gets its chance to run.
> > 
> > Right.  So it should work, good!
> Now the problem is how to cancel the notification request explicitly.

It should just be a matter of adding the support in libports that
requests it from the kernel but also cleans it in the lists, as Frederik
said.

Samuel