Re: [PATCH] Check for rendezvous port death in auth server

[Carl Fredrik Hammar]

Hi,

On Thu, Jun 03, 2010 at 06:55:12AM +0200, olafBuddenhagen@gmx.net wrote:
> On Wed, Jun 02, 2010 at 06:35:02PM +0200, Carl Fredrik Hammar wrote:
> > On Wed, Jun 02, 2010 at 12:17:12AM +0200, olafBuddenhagen@gmx.net
> > wrote:
> 
> > > I'm a bit ambivalent about this... On one hand, returning the right
> > > error code right away is probably less confusing; but on the other
> > > hand, it adds extra code paths (with all the associated
> > > disadvantages) for something that just works in a natural fashion
> > > right now -- which in a way is actually more elegant...
> > 
> > I'm mostly concerned with code which want to report the interruption
> > error.  I mean, is it really mandated that interrupted operations
> > should be retried?  Consider a program that doesn't handle any signals
> > and doesn't otherwise expect an interruption, then it would report the
> > wrong error.
> 
> Isn't that normally abstracted by glibc? I.e. only programs invoking the
> RPC manually would have to do the EINTR check themselfs?

Yes, but I don't think RPCs should deviate from the normal convention
without good reason.  If this "bug" affected non-Hurd specific programs,
I think this discussion would be a lot shorter.  :-)

> BTW I have some recollection that it *is* actually mandated by POSIX
> that EINTR should always be handled -- though I might be misremembering
> or confusing something... In either case, it's true that most programs
> don't observe this, and in fact it would be really painful to do so :-(
> (This is a generic remark though; I don't think it applies in the
> situation discussed here.)

I looked it up and it seems POSIX agrees with my intuition on when
interrupts happen.  Here, it states that a function is only interrupted
if a signal-catching function is called to handle the signal:
http://www.opengroup.org/onlinepubs/9699919799/functions/V2_chap02.html#tag_15_04_04

I also investigated a bit more out of curiosity.  I was unsure if EINTR
happens on a SIGCONT to a stopped process, and a gdb session revealed that
auth_user_authenticate is automatically restarted by glibc in this case.
In all the other cases, the signal is ignored or terminates the process
by default.

Given all this, it is not unreasonable for a program to assume that a
function won't get interrupted unless it actually messes around with
signals.

> > In fact, I recently suffered such confusion in a similar case where I
> > accidentally sent a null port to auth, which resulted in EINTR.  At
> > first I thought that gdb was somehow interfering with some sort of
> > signal handling. (It wouldn't have been the first time gdb and signals
> > mess things up for me.)
> > 
> > This also tells me that we should be testing for null ports as well.
> > Though this only needs to be done in the beginning of the function
> > since there is no risk of a port becoming null.  Actually, since
> > there's currently no testing at all you'll loop indefinitely if you
> > restart!
> 
> I don't fully understand the situation -- but this sounds like something
> that should be catched early, so it doesn't even enter the RPC
> interruption code path...

Sorry, should've expressed it more clearly, but yes, that is what I
meant by doing it "in the beginning of the function".  (This'll go into
a separate patch, of course.)

Regadrs,
  Fredrik