Re: Reauthentication implementation flaw due to EINTR

[Da Zheng]

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.
> The RPC that could get
> canceled is auth_server_authenticate().  Mmm, that makes me realize that
> this could be the link with ext2fs indeed.
> 
>>> I actually believe that's already the case: libports remembers the
>>> notification request and disables it on RPC termination, which should be
>>> enough for itself.  What I still don't understand is the link between
>>> auth requesting a notification and ext2fs also getting the EINTR.
>> As Fredrik said and as I understand, while the server side of
>> auth_server_authenticate RPC is waiting for the signal from the
>> auth_user_authenticate, auth_server_authenticate RPC can be canceled by the
>> deadname notification if the client gets scheduled first and destroys the
>> rendezvous port and thus the auth_server_authenticate RPC returns EINTR.
> 
> Right.
> 
>> The right thing to do is that before the server side of
>> auth_user_authenticate RPC returns, it cancels the deadname
>> notification.
> 
> 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.

Zheng Da