Re: Reauthentication implementation flaw due to EINTR

[Samuel Thibault]

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

Samuel