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

[Ian Lepore]

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