svn commit: r312296 - in head: lib/libc/sys sys/kern sys/netinet sys/netinet6 sys/sys tools/regression/sockets/udp_pingpong tools/regression/sockets/unix_cmsg

[Maxim Sobolev]

Alan, I doubt SO_BINTIME / SO_TIMESTAMP ever worked in that scenario. The
reason for that is size/layout of the bintime (and other structs) is
different on amd64 as compared to i386 and I don't see any conversion going
on in the freebsd32_recvmsg().

                 i386  x86_64
sizeof(timeval)     8      16
sizeof(bintime)    12      16
sizeof(timespec)    8      16

Thereby, first the buffer supplied by the i386 app is not going to be
sufficient (causing MSG_CTRUNC). Or even if the app on the receiving end
overcommits for whatever reason, it's not going to be able parse the
returned structures correctly. This is actually the case with the
udp_pingpong, that is also not working properly in emulation mode:

[tools/regression/sockets/udp_pingpong]$ ./udp_pingpong
Testing send()/recv() via IPv4: OK
Testing send()/recvmsg(), setsockopt(SO_TIMESTAMP, 1) via IPv4:
udp_pingpong: A2B trip time is not positive

Therefore, the i386 emulation code needs to be extended to actually parse
into cmghdr structure(s) and to do a proper type conversion between 32 and
64 bit versions of the struct timeval, struct bintime and struct timespec.

I have a patch in works to get it fixed, stay tuned.

-Max

On Mon, Sep 4, 2017 at 7:09 PM, Maxim Sobolev <sobomax at freebsd.org> wrote:

> Sure, I'll check that out. Thanks for heads up.
>
> -Max
>
> On Sun, Sep 3, 2017 at 8:18 PM, Alan Somers <asomers at freebsd.org> wrote:
>
>> On Mon, Jan 16, 2017 at 10:46 AM, Maxim Sobolev <sobomax at freebsd.org>
>> wrote:
>> > Author: sobomax
>> > Date: Mon Jan 16 17:46:38 2017
>> > New Revision: 312296
>> > URL: https://svnweb.freebsd.org/changeset/base/312296
>> >
>> > Log:
>> >   Add a new socket option SO_TS_CLOCK to pick from several different
>> clock
>> >   sources to return timestamps when SO_TIMESTAMP is enabled. Two
>> additional
>> >   clock sources are:
>> >
>> >   o nanosecond resolution realtime clock (equivalent of CLOCK_REALTIME);
>> >   o nanosecond resolution monotonic clock (equivalent of
>> CLOCK_MONOTONIC).
>> >
>> >   In addition to this, this option provides unified interface to get
>> bintime
>> >   (equivalent of using SO_BINTIME), except it also supported with IPv6
>> where
>> >   SO_BINTIME has never been supported. The long term plan is to
>> depreciate
>> >   SO_BINTIME and move everything to using SO_TS_CLOCK.
>> >
>> >   Idea for this enhancement has been briefly discussed on the Net
>> session
>> >   during dev summit in Ottawa last June and the general input was
>> positive.
>> >
>> >   This change is believed to benefit network benchmarks/profiling as
>> well
>> >   as other scenarios where precise time of arrival measurement is
>> necessary.
>> >
>> >   There are two regression test cases as part of this commit: one
>> extends unix
>> >   domain test code (unix_cmsg) to test new SCM_XXX types and another one
>> >   implementis totally new test case which exchanges UDP packets between
>> two
>> >   processes using both conventional methods (i.e. calling
>> clock_gettime(2)
>> >   before recv(2) and after send(2)), as well as using
>> setsockopt()+recv() in
>> >   receive path. The resulting delays are checked for sanity for all
>> supported
>> >   clock types.
>> >
>> >   Reviewed by:    adrian, gnn
>> >   Differential Revision:  https://reviews.freebsd.org/D9171
>>
>> While the new SCM_TIMESTAMP code works fine on both amd64 and i386, it
>> doesn't work on amd64 under 32-bit emulation.  That is, programs that
>> use SCM_TIMESTAMP built for i386 will fail when run on an amd64
>> machine.  I don't know whether this commit introduced that bug; on
>> stable-10 SCM_TIMESTAMP doesn't appear to work at all on i386.  But
>> sobomax, since you're obviously familiar with this code, would you
>> mind taking a look?
>> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=222039
>>
>> -Alan
>>
>>
>