[Proposed Fix] daemon.c: not initializing revents

[Proposed Fix] daemon.c: not initializing revents

[Randall S. Becker]

Hi All,

I found this while trying to track down a hang in t5562 - this isn't the
fix, but here it is something that could be considered a code-inspection. If
there have been random unexplained hangs when git runs as a daemon, this
might be the cause.

According to many systems (other than Linux), the revents field is supposed
to be 0 on return to poll(). This was the cause of some heart-ache a while
back in compat/poll/poll.c. I am not certain whether that copy of poll() is
used in daemon, but I wanted to point out that the value is being returned
to poll, outside of compat/poll/poll.c and may present a potential for poll
returning an error on that FD due to random values that might be in revents.

Please see 61b2a1acaae for a related change/justification.

diff --git a/daemon.c b/daemon.c
index 9d2e0d20ef..1e275fc8b3 100644
--- a/daemon.c
+++ b/daemon.c
@@ -1194,6 +1194,7 @@ static int service_loop(struct socketlist *socklist)
                                }
                                handle(incoming, &ss.sa, sslen);
                        }
+                       pfd[i].revents = 0;
                }
        }
 }

Regards,
Randall

Re: [Proposed Fix] daemon.c: not initializing revents

[Junio C Hamano]

"Randall S. Becker" <rsbecker@nexbridge.com> writes:

> Hi All,
>
> I found this while trying to track down a hang in t5562 - this isn't the
> fix, but here it is something that could be considered a code-inspection. If
> there have been random unexplained hangs when git runs as a daemon, this
> might be the cause.
>
> According to many systems (other than Linux), the revents field is supposed
> to be 0 on return to poll(). This was the cause of some heart-ache a while
> back in compat/poll/poll.c.

I am having a hard time grokking "supposed to be 0 on return to",
but do you mean "the caller must clear .revents field before calling
poll()"?

http://pubs.opengroup.org/onlinepubs/9699919799/functions/poll.html
has this 

    In each pollfd structure, poll() shall clear the revents member,
    except that where the application requested a report on a condition
    by setting one of the bits of events listed above, poll() shall set
    the corresponding bit in revents if the requested condition is
    true. In addition, poll() shall set the POLLHUP, POLLERR, and
    POLLNVAL flag in revents if the condition is true, even if the
    application did not set the corresponding bit in events.

and I am also having a hard time interpreting the "except that".  If
we asked to report (e.g. we set POLLIN in the .events field), poll()
does not have to clear .revents but just set whatever bits it needs
to set to report the condition in the field?  

If that is the case, it makes it a bug not to clear .revents before
calling poll; the sample code snippet on the same page in EXAMPLES
section does not, though, so I am puzzled.

In any case, no matter what POSIX says, if clearing .revents before
calling poll() helps on platforms in the real world, the patch is
worth taking as a fix, I would think.

> I am not certain whether that copy of poll() is
> used in daemon, but I wanted to point out that the value is being returned
> to poll, outside of compat/poll/poll.c and may present a potential for poll
> returning an error on that FD due to random values that might be in revents.
>
> Please see 61b2a1acaae for a related change/justification.
>
> diff --git a/daemon.c b/daemon.c
> index 9d2e0d20ef..1e275fc8b3 100644
> --- a/daemon.c
> +++ b/daemon.c
> @@ -1194,6 +1194,7 @@ static int service_loop(struct socketlist *socklist)
>                                 }
>                                 handle(incoming, &ss.sa, sslen);
>                         }
> +                       pfd[i].revents = 0;
>                 }
>         }
>  }
>
> Regards,
> Randall

RE: [Proposed Fix] daemon.c: not initializing revents

[Randall S. Becker]

On February 11, 2019 15:57, Junio C Hamano wrote:
> "Randall S. Becker" <rsbecker@nexbridge.com> writes:
> 
> > Hi All,
> >
> > I found this while trying to track down a hang in t5562 - this isn't
> > the fix, but here it is something that could be considered a
> > code-inspection. If there have been random unexplained hangs when git
> > runs as a daemon, this might be the cause.
> >
> > According to many systems (other than Linux), the revents field is
> > supposed to be 0 on return to poll(). This was the cause of some
> > heart-ache a while back in compat/poll/poll.c.
> 
> I am having a hard time grokking "supposed to be 0 on return to", but do
you
> mean "the caller must clear .revents field before calling poll()"?
> 
> http://pubs.opengroup.org/onlinepubs/9699919799/functions/poll.html
> has this
> 
>     In each pollfd structure, poll() shall clear the revents member,
>     except that where the application requested a report on a condition
>     by setting one of the bits of events listed above, poll() shall set
>     the corresponding bit in revents if the requested condition is
>     true. In addition, poll() shall set the POLLHUP, POLLERR, and
>     POLLNVAL flag in revents if the condition is true, even if the
>     application did not set the corresponding bit in events.
> 
> and I am also having a hard time interpreting the "except that".  If we
asked
> to report (e.g. we set POLLIN in the .events field), poll() does not have
to
> clear .revents but just set whatever bits it needs to set to report the
> condition in the field?
> 
> If that is the case, it makes it a bug not to clear .revents before
calling poll;
> the sample code snippet on the same page in EXAMPLES section does not,
> though, so I am puzzled.
> 
> In any case, no matter what POSIX says, if clearing .revents before
calling
> poll() helps on platforms in the real world, the patch is worth taking as
a fix, I
> would think.

That's what my intent was - my explanations are suffering from a little
work-induced sleep deprivation. Would you like this as a formal patch?

> 
> > I am not certain whether that copy of poll() is used in daemon, but I
> > wanted to point out that the value is being returned to poll, outside
> > of compat/poll/poll.c and may present a potential for poll returning
> > an error on that FD due to random values that might be in revents.
> >
> > Please see 61b2a1acaae for a related change/justification.
> >
> > diff --git a/daemon.c b/daemon.c
> > index 9d2e0d20ef..1e275fc8b3 100644
> > --- a/daemon.c
> > +++ b/daemon.c
> > @@ -1194,6 +1194,7 @@ static int service_loop(struct socketlist
*socklist)
> >                                 }
> >                                 handle(incoming, &ss.sa, sslen);
> >                         }
> > +                       pfd[i].revents = 0;
> >                 }
> >         }
> >  }

Regards,
Randall

Re: [Proposed Fix] daemon.c: not initializing revents

[Junio C Hamano]

"Randall S. Becker" <rsbecker@nexbridge.com> writes:

>> In any case, no matter what POSIX says, if clearing .revents before
> calling
>> poll() helps on platforms in the real world, the patch is worth taking as
> a fix, I
>> would think.
>
> That's what my intent was - my explanations are suffering from a little
> work-induced sleep deprivation. Would you like this as a formal patch?

That depends ;-)

At this late in the cycle, I do not see much urgency for this patch
to be in the upcoming release (after all, this code survived real
world for quite a long time, so it's only minority platforms like
NonStop that haven't seen serious porting effort until recently that
would see improvement---and they have survived without reliably
working daemon for so long that they can wait for one more release).

Now, the knowledge that we will have long enough time before the
final version of the formal patch becomes necessary makes me wonder
what the best use of that time to polish the patch would be.  Ideally
we'd like to see "this definitely fixed (or 'worked around') such
and such breakages on platform X, Y and Z" instead of my "Well, we
could read POSIX that way, so there may be some platforms that would
require applications to do this, and an extra assignment here would
certainly not hurt", which was the hand-waving I just did.

I dunno.

RE: [Proposed Fix] daemon.c: not initializing revents

[Randall S. Becker]

On February 11, 2019 21:59, Junio C Hamano wrote:
> "Randall S. Becker" <rsbecker@nexbridge.com> writes:
> 
> >> In any case, no matter what POSIX says, if clearing .revents before
> > calling
> >> poll() helps on platforms in the real world, the patch is worth
> >> taking as
> > a fix, I
> >> would think.
> >
> > That's what my intent was - my explanations are suffering from a
> > little work-induced sleep deprivation. Would you like this as a formal
> patch?
> 
> That depends ;-)
> 
> At this late in the cycle, I do not see much urgency for this patch to be
in the
> upcoming release (after all, this code survived real world for quite a
long
> time, so it's only minority platforms like NonStop that haven't seen
serious
> porting effort until recently that would see improvement---and they have
> survived without reliably working daemon for so long that they can wait
for
> one more release).
> 
> Now, the knowledge that we will have long enough time before the final
> version of the formal patch becomes necessary makes me wonder what the
> best use of that time to polish the patch would be.  Ideally we'd like to
see
> "this definitely fixed (or 'worked around') such and such breakages on
> platform X, Y and Z" instead of my "Well, we could read POSIX that way, so
> there may be some platforms that would require applications to do this,
and
> an extra assignment here would certainly not hurt", which was the hand-
> waving I just did.
> 
> I dunno.

I hear that. I'd rather (not) be working on debugging breakages from other
authors that impact my platform. Honestly, I'd rather work at my $DAYJOB,
although, some days...

Since this topic isn't a breakage per-se (no tests seem to be impacted on
way or another), I agree that this can wait and get through the normal cycle
of events at some point in the future. Now, if I could only get some help on
t5562 ;) that would be time well spent for rc0.

Cheers,
Randall