From owner-svn-src-all@freebsd.org Thu Sep 12 20:08:45 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 9D4DFD90BE for ; Thu, 12 Sep 2019 20:08:45 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound3d.ore.mailhop.org (outbound3d.ore.mailhop.org [54.186.57.195]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 46TqbK1c3Xz3DGh for ; Thu, 12 Sep 2019 20:08:45 +0000 (UTC) (envelope-from ian@freebsd.org) ARC-Seal: i=1; a=rsa-sha256; t=1568318924; cv=none; d=outbound.mailhop.org; s=arc-outbound20181012; b=UYFP/vrXt/3GLIVJUL8rRm6ko27fIpo6h2B4Pns1VmrwW/SQnuIxVxydKpQRCOZXC2hcaVv2Jj+yK C7XypvgmPF+ljwPHRpRrN5+mQEGFRGjPNGZi56bI/JYwgtmf0+vATfJYVbSH/iEVQ3+PEZHhpr3plX aQ0YqR2cacZjOShV124hECxiKvGqCpQ2RXhnIZeGTWIQAHd0pb2wPWbEHOc83gra2Rek5ToaQ3a3jf 8Ik2dLcIg+haqImfT8BXAiIQYTwezTMTHnfiiil7YdI0RZF90WyFtcEW5KXXi2jyBmx1PIj5/XrGXx FZLEMlObnDu341pdS8hFiXs7x+Y+Dnw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=arc-outbound20181012; h=content-transfer-encoding:mime-version:content-type:references:in-reply-to: date:cc:to:from:subject:message-id:dkim-signature:from; bh=+SFcU6BMrUjrAXMTS6OGGwBtArUnAoudLl9sEDveU9k=; b=thvX/3I/0DAl1UFByhmnCWG5wLXxksFGaXnVPuJevMyLCJYn2mNSQVkmQWVlbUCEnnausnmR6zBy3 r7StxLmAcaHJBkpuLZyd8NpCYQsS23GfaqoyiAy+jon+5XDXwhC9XO3QQ1qNYV6vl8pS4G4v5571C5 ZpgpeFWUeB0OhvfMAgjNs08+VPS/wKobIXAJFtcF8DFq3zPNVl7SCZPyFXAdWJobTdrZP6i5d8EFqL mis/ZJKyPWEjMINq82MaxhxKTszaFY+jPm1hBS71XtnR3N/E/PEN2yP0Ikj+vMCaI2BDO4QXWpDJ3x IHvznJlazTMyeSswzExhXRr09TLmqsQ== ARC-Authentication-Results: i=1; outbound3.ore.mailhop.org; spf=softfail smtp.mailfrom=freebsd.org smtp.remote-ip=67.177.211.60; dmarc=none header.from=freebsd.org; arc=none header.oldest-pass=0; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=dkim-high; h=content-transfer-encoding:mime-version:content-type:references:in-reply-to: date:cc:to:from:subject:message-id:from; bh=+SFcU6BMrUjrAXMTS6OGGwBtArUnAoudLl9sEDveU9k=; b=dOa3jal0KpkFXN86TFsbKWMPOjEu+3PIRGNIOn0DUhRE31qOCPxhiv5tLFXPJtMZh1qXCkVIWvYrI tHUcaiXU/YX8MOSUGny02whI3mo/lmw/H+Ns80IvIt8BDhpArE0Qihp6QXwDDCQ0B/GPtl9Gth86Cz sdHE8bJkhDcUiA0vjNJfznS5hZN0DwM1/jZQx17cQEJokQn53MWwCwMf8aMW05OR9j0ctGpDs/nFUu fMM0w2yD32VudMCB8xG3y3Dd5x/Eid5BrFg/9ldyyEzp8ETUy83eOjuMrNuWEhMShpRvTs4eZWpopj d/oeVMpQUli9LtAcONj6A4iop5lxjdg== X-MHO-RoutePath: aGlwcGll X-MHO-User: 1cdd7cf8-d599-11e9-b67d-cdd75d6ce7a8 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 67.177.211.60 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [67.177.211.60]) by outbound3.ore.mailhop.org (Halon) with ESMTPSA id 1cdd7cf8-d599-11e9-b67d-cdd75d6ce7a8; Thu, 12 Sep 2019 20:08:41 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id x8CK8dXN079051; Thu, 12 Sep 2019 14:08:40 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <20f4e7af5b82e47fddf604975ff3e853c231720d.camel@freebsd.org> Subject: Re: svn commit: r352231 - head/lib/libc/sys From: Ian Lepore To: Cy Schubert Cc: Alan Somers , src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Date: Thu, 12 Sep 2019 14:08:39 -0600 In-Reply-To: <201909122002.x8CK2Sxh005042@slippy.cwsent.com> References: <201909111948.x8BJmWZn092483@repo.freebsd.org> <63cf915c92b92b07e19337849269ec6bd0dc0d1b.camel@freebsd.org> <201909122002.x8CK2Sxh005042@slippy.cwsent.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.28.5 FreeBSD GNOME Team Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 46TqbK1c3Xz3DGh X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-2.00 / 15.00]; local_wl_from(0.00)[freebsd.org]; NEURAL_HAM_MEDIUM(-1.00)[-0.999,0]; ASN(0.00)[asn:16509, ipnet:54.186.0.0/15, country:US]; NEURAL_HAM_LONG(-1.00)[-1.000,0] 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: Thu, 12 Sep 2019 20:08:45 -0000 On Thu, 2019-09-12 at 13:02 -0700, Cy Schubert wrote: > In message < > 63cf915c92b92b07e19337849269ec6bd0dc0d1b.camel@freebsd.org>, > Ian Le > pore writes: > > 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 a > > > > s > > > ancillary data to each IP datagram that is received on the > > > socket. Howeve > > > > r, > > > 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 (r35223 > > > > 0) > > > +++ head/lib/libc/sys/getsockopt.2 Wed Sep 11 19:48:32 > > > 2019 (r35223 > > > > 1) > > > @@ -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 receiv > > > > ed. > > > +call may return a timestamp corresponding to when the datagram > > > was receive > > > > d. > > > +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. > > This reminds me, something that's been on my plate for a couple of > weeks. > Our NTP upline pinged me a few weeks ago regarding IEEE 1588 driver > support > for NICs with hardware support. Linux already has it. I was told > that > someone hrtr has attempted this but that the results weren't > optimal. > That's all I know. Should I open discussion on arch@? It's something I've been wanting to do for a while, and something that would be helpful at $work, so a discussion on it sounds like a good idea. -- Ian