From owner-svn-src-all@freebsd.org Wed Sep 11 21:55:34 2019 Return-Path: Delivered-To: svn-src-all@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id BAA17E12A7; Wed, 11 Sep 2019 21:55:34 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-lf1-f46.google.com (mail-lf1-f46.google.com [209.85.167.46]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 46TG124WpWz4Sgh; Wed, 11 Sep 2019 21:55:34 +0000 (UTC) (envelope-from asomers@gmail.com) Received: by mail-lf1-f46.google.com with SMTP id c195so2699318lfg.9; Wed, 11 Sep 2019 14:55:34 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=qKsqgvGf/QFB5zoWyXHIhBPLrQIOGZoIVX4TrfSBceE=; b=rwxDvXj7smvasXr5SUv7S8raMTktV03IJy9141exAkFoUouuMQ8/VlZqUrdWePqDqo NOfXdANBbNa3bLZE4SInWjDS2RK6DfQ0QS/y0fUxl9p0ZSRx5ZSgoA2/gTQZsm3tAF/a PHJ4ta2/pWDfDcvG6pfBmFQgSPvr84FSsFyzKdemTJrassNuwSLLXHfGZp0S/iCJ3PMx WU7qf7rMvCvhJFI/tNUtXx4TP3QAfowgFvwQ1CbQZ6+46q8hHSZFbOoQA6n8L3cxwgAL AW++OPHu936s1TxbmcrfQCrm4miIVklXySFfG0S78P51DYibDfZAaNuQmLJIb4+R1B5f b4tw== X-Gm-Message-State: APjAAAW6OIb9KAdKJJtVMm4Wle5PcimA88fcaK9VXoBLSpPqOR5WkLjL edrqdQj4aJ5EQybUggMbsvAPbLequuG5O6PKa3eePA== X-Google-Smtp-Source: APXvYqwOpv9zux2IEEf4wAaNLLM1t++dsm2J+qKdrIKABbkgdnBQbfRCUDDNUb5tY+TNCnCJ5ikV0ahMCdmJizx+G/A= X-Received: by 2002:a19:cc4f:: with SMTP id c76mr25217749lfg.117.1568238932559; Wed, 11 Sep 2019 14:55:32 -0700 (PDT) MIME-Version: 1.0 References: <201909111948.x8BJmWZn092483@repo.freebsd.org> <63cf915c92b92b07e19337849269ec6bd0dc0d1b.camel@freebsd.org> In-Reply-To: <63cf915c92b92b07e19337849269ec6bd0dc0d1b.camel@freebsd.org> From: Alan Somers Date: Wed, 11 Sep 2019 15:55:20 -0600 Message-ID: Subject: Re: svn commit: r352231 - head/lib/libc/sys To: Ian Lepore , Peter Holm Cc: src-committers , svn-src-all , svn-src-head X-Rspamd-Queue-Id: 46TG124WpWz4Sgh X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-6.00 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-0.999,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; REPLY(-4.00)[] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Sep 2019 21:55:34 -0000 On Wed, Sep 11, 2019 at 3:50 PM Ian Lepore 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