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
sobomax at freebsd.org
Wed Sep 6 22:29:36 UTC 2017
No problem, it also suggests somebody seriously interested in the 32-bit
emulation might find entertaining running regression tests both natively
and in the i386->amd64 mode comparing results, it could bring some
interesting corner cases and pitfalls of the compat/freebsd32 to light.
I've also made some generic improvements into the udp_pingpong to catch
anomality in returned data length as well as to handle MSG_CTRUNC and
premature departure of the other side more gracefully.
-Max
On Wed, Sep 6, 2017 at 2:31 PM, Alan Somers <asomers at freebsd.org> wrote:
> Cool. Thanks for looking into it.
>
> On Wed, Sep 6, 2017 at 3:15 PM, Maxim Sobolev <sobomax at freebsd.org> wrote:
> > 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
> >>>
> >>
> >
>
>
More information about the svn-src-all
mailing list