From owner-svn-src-head@freebsd.org Wed Sep 6 22:29:35 2017 Return-Path: Delivered-To: svn-src-head@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6312EE1ACCE for ; Wed, 6 Sep 2017 22:29:35 +0000 (UTC) (envelope-from sobomax@sippysoft.com) Received: from mail-ua0-x235.google.com (mail-ua0-x235.google.com [IPv6:2607:f8b0:400c:c08::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E6D4771969 for ; Wed, 6 Sep 2017 22:29:34 +0000 (UTC) (envelope-from sobomax@sippysoft.com) Received: by mail-ua0-x235.google.com with SMTP id c27so16258321uah.2 for ; Wed, 06 Sep 2017 15:29:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sippysoft-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=C8yabytOP9KyzPdk6UOEiT78FoENII4gAv6OgtKuwQg=; b=conJlv+2ZD2Q0amnaVyY3v9Ug6KNcpbcEh6X+X6zrTjQRp50mO4tyFM7zTNaqjihFm c9IPE7NfWTYbrw21d06tFx5oBxj+cmIHFmHxykS2yV1hlrSla51Hc/uj7VmCMHqXKvl7 5xy46RyCMrOOEAPk8f+9vBFCUiKt3PYiw6FDmdR9cNUK0v/ZzhiDIFMWDknZugUMr9qy Nz35E9x4D/hMIcu0ANrbNrayOe229g8eRRnQ9Dj6qeYkIfAiuxLlYXYLA5cdK6qCh4kk 2ZWu5VbA6HVIDTPXpoHEa4IAJPnmVOw5S62DoPnah9QNHiT+d7vGa2DNRjMpCtfu6u9a BKaQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=C8yabytOP9KyzPdk6UOEiT78FoENII4gAv6OgtKuwQg=; b=AUJCsO1coXsXdLFpjc7DhnLTVez0aN+92Kf/R/GoXjB+iFBxMW0HOmVdijATCzSjKm OAbd0FpDGEB+tQ1aUBO7PwD2Ie/nnqbZ76dT6mYq/otikakO9b2lvjUoLNhLXYQFphe+ VTgkydu13gmq/+PxdJrWkFLrLuai5o+QjUffbEsD1An10TcpSEAq6POu2NvUBDXkaUYg wwXPwiuEjYYzfJ6XSPQym0qlfPZWruboPdJJi0tDb3ZrH0gEyHenf/EDRb4uuiXRBg2y yKI5NAx3W6JmxV0jWqWae5OV/36KZoC9syi1mEu+gjIbmAvkKKeOKWIevJCbi7djC+ao ErJA== X-Gm-Message-State: AHPjjUiFYRFi4jp+h/ce7nYkARY0rJewz667eGx4ta32eE/wvD8jf6hG 7lDtJsC/KhWISi44UYVKTQrY5DSVYJF3 X-Google-Smtp-Source: ADKCNb4L1oa5Sgr7AQb0IOPjK4ahRsNBl/83mlHTP3osylfkXahpZ36JM010RH2bJY45bfyXS9Fl8oSvWXO/zCKvKkc= X-Received: by 10.176.20.103 with SMTP id c36mr390816uae.137.1504736973755; Wed, 06 Sep 2017 15:29:33 -0700 (PDT) MIME-Version: 1.0 Sender: sobomax@sippysoft.com Received: by 10.176.6.137 with HTTP; Wed, 6 Sep 2017 15:29:33 -0700 (PDT) Received: by 10.176.6.137 with HTTP; Wed, 6 Sep 2017 15:29:33 -0700 (PDT) In-Reply-To: References: <201701161746.v0GHkcPX071529@repo.freebsd.org> From: Maxim Sobolev Date: Wed, 6 Sep 2017 15:29:33 -0700 X-Google-Sender-Auth: Iec_oeXJCD4NUzuXQcPbnkpFspw Message-ID: Subject: Re: 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 To: Alan Somers Cc: src-committers , svn-src-all@freebsd.org, "svn-src-head@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Sep 2017 22:29:35 -0000 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 wrote: > Cool. Thanks for looking into it. > > On Wed, Sep 6, 2017 at 3:15 PM, Maxim Sobolev 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 > wrote: > >> > >> Sure, I'll check that out. Thanks for heads up. > >> > >> -Max > >> > >> On Sun, Sep 3, 2017 at 8:18 PM, Alan Somers > wrote: > >>> > >>> On Mon, Jan 16, 2017 at 10:46 AM, Maxim Sobolev > >>> 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 > >>> > >> > > > >