From owner-svn-src-head@freebsd.org Wed Sep 6 21:15:15 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 E70AAE17A20 for ; Wed, 6 Sep 2017 21:15:15 +0000 (UTC) (envelope-from sobomax@sippysoft.com) Received: from mail-vk0-x235.google.com (mail-vk0-x235.google.com [IPv6:2607:f8b0:400c:c05::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 8EE2C1761 for ; Wed, 6 Sep 2017 21:15:15 +0000 (UTC) (envelope-from sobomax@sippysoft.com) Received: by mail-vk0-x235.google.com with SMTP id t10so13848973vke.0 for ; Wed, 06 Sep 2017 14:15:15 -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=1u73Vczt9peff0fbC7V0cHH4SavGeHSSwefXlY/4XB8=; b=qs/Vtji/ejt+qCJhsALI+QrO2wj5BdBhhFmtArgrbRiAaYpFLiXYl1N6Pg5BLKYITj c6eG5zTG8LoRbrSWnsdyqTt0ODsplwn7ZRyHTeBJG1ckCW8GB8LtK8Gb68m0arlJmqLe EtJ5b/1FyGL5lhWWOzkP5ES+WKkptXJDgYCjDibCERZSHJhicP1C+u9kHXpDDeANbBsi PHrC/XaxscIECZpU0+VUUvHyMtFt7YL6fw+ibtxZ+sr7CKbmhoGk0n4vdVV+x9UWdGwu QKpQm6fVLMbBPJQsLbj7XPla+I18O6RF54rXr+ufLH15nCNYM9AvXfSypcRNqm+ruIhh f5/w== 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=1u73Vczt9peff0fbC7V0cHH4SavGeHSSwefXlY/4XB8=; b=aFPHst5Ut4a24rJoCVYtTDTuY1bXpA1uKUHNxHyqPZxFa0jZDzBz0WNGAyLH7NtsXo 7bwRccBQkgo8hSOcJ7tFJJlmRBGx+aNNGq+R0igxEugN9e/5iFhWbtN+LS4kMtk1rzXo Qzf+X8sRo3vAM1/iSRB3nmm4dnjQzqwR5jdMcgeI9CUbqHoyTsysaO4OYDPCt/ZVTTFS WOdTkrfuKHlciTdz5NSV6EatzQfWn9oW1U7/2d0e9/lGqlJU7YxDZ37wk0CETelEcoU6 BBb9mXGNaumLZ/L+9qqOMF63gkYvYzdEsUrl2tY9gMn6rvy8ljNBJgP3l0hj4WFRdhvJ SX+Q== X-Gm-Message-State: AHPjjUj9aayPGXrVMahTJ2DuZ3hy1M4D0K3whTkHkeqNzt0Jc0+HoVia 2CrpoyzalPkGvKusaLBZ9xhlwZOTITto X-Google-Smtp-Source: ADKCNb55os/jd6I50Ef5zcipX4nzBw+lGs193t0L9tQqV9WkPd3SlmhgNCfjNYCs7chr5GGYig9cyqont3IFgY8vuMw= X-Received: by 10.31.181.208 with SMTP id e199mr290927vkf.55.1504732514143; Wed, 06 Sep 2017 14:15:14 -0700 (PDT) MIME-Version: 1.0 Sender: sobomax@sippysoft.com Received: by 10.176.6.137 with HTTP; Wed, 6 Sep 2017 14:15:13 -0700 (PDT) In-Reply-To: References: <201701161746.v0GHkcPX071529@repo.freebsd.org> From: Maxim Sobolev Date: Wed, 6 Sep 2017 14:15:13 -0700 X-Google-Sender-Auth: lsBmAbyqkMbxSTg-cQF888vIecI 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@freebsd.org" , "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 21:15:16 -0000 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 >> >> >