svn commit: r352231 - head/lib/libc/sys

[Ian Lepore]

On Wed, 2019-09-11 at 15:55 -0600, Alan Somers wrote:
> On Wed, Sep 11, 2019 at 3:50 PM Ian Lepore <ian at freebsd.org> wrote:
> 
> > On Wed, 2019-09-11 at 19:48 +0000, Alan Somers wrote:
> > > Author: asomers
> > > Date: Wed Sep 11 19:48:32 2019
> > > New Revision: 352231
> > > URL: https://svnweb.freebsd.org/changeset/base/352231
> > > 
> > > Log:
> > >   getsockopt.2: clarify that SO_TIMESTAMP is not 100% reliable
> > > 
> > >   When SO_TIMESTAMP is set, the kernel will attempt to attach a
> > 
> > timestamp as
> > >   ancillary data to each IP datagram that is received on the socket.
> > 
> > However,
> > >   it may fail, for example due to insufficient memory. In that case the
> > >   packet will still be received but not timestamp will be attached.
> > > 
> > >   Reviewed by:        kib
> > >   MFC after:  3 days
> > >   Differential Revision:      https://reviews.freebsd.org/D21607
> > > 
> > > Modified:
> > >   head/lib/libc/sys/getsockopt.2
> > > 
> > > Modified: head/lib/libc/sys/getsockopt.2
> > > 
> > 
> > ==============================================================================
> > > --- head/lib/libc/sys/getsockopt.2    Wed Sep 11 19:29:40 2019
> > 
> > (r352230)
> > > +++ head/lib/libc/sys/getsockopt.2    Wed Sep 11 19:48:32 2019
> > 
> > (r352231)
> > > @@ -28,7 +28,7 @@
> > >  .\"     @(#)getsockopt.2     8.4 (Berkeley) 5/2/95
> > >  .\" $FreeBSD$
> > >  .\"
> > > -.Dd February 10, 2019
> > > +.Dd September 11, 2019
> > >  .Dt GETSOCKOPT 2
> > >  .Os
> > >  .Sh NAME
> > > @@ -431,7 +431,8 @@ option is enabled on a
> > >  .Dv SOCK_DGRAM
> > >  socket, the
> > >  .Xr recvmsg 2
> > > -call will return a timestamp corresponding to when the datagram was
> > 
> > received.
> > > +call may return a timestamp corresponding to when the datagram was
> > 
> > received.
> > > +However, it may not, for example due to a resource shortage.
> > >  The
> > >  .Va msg_control
> > >  field in the
> > > 
> > 
> > So I guess this actually happened to someone... is it a common thing
> > for the timestamp to fail?  I ask because ntpd relies on SO_TIMESTAMP
> > and if this situation really happens and can persist for a long time,
> > ntpd would effectively stop working.
> > 
> > -- Ian
> > 
> 
> pho discovered how to trigger it.  If you start 50 ping processes
> simultaneously, sometimes a few will fail.  Will ntpd be ok with a single
> failure, as long as the timestamp is received correctly in a subsequent
> packet?
> -Alan

Yeah, nptd is resilient to missing data and intermittent comms, within
reason.  If it goes hours without getting a timestamp, system time
would start to drift.  Running 50 concurrent pings sounds like
something that won't come up in the real world. :)

-- Ian