From owner-freebsd-current@FreeBSD.ORG Fri Aug 23 06:27:59 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 894D31C4; Fri, 23 Aug 2013 06:27:59 +0000 (UTC) (envelope-from vitja.makarov@gmail.com) Received: from mail-vc0-x235.google.com (mail-vc0-x235.google.com [IPv6:2607:f8b0:400c:c03::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 359992FCA; Fri, 23 Aug 2013 06:27:59 +0000 (UTC) Received: by mail-vc0-f181.google.com with SMTP id hz10so171528vcb.12 for ; Thu, 22 Aug 2013 23:27:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=OXLN54b7Mcjn9/HXNA6zkxh2Vc3usNd2IGN6GHykjdc=; b=dk2qJBP+aCsBL6rTRc5y3XW4ncgbAz/hKmLzGJSmWlNG8jE07t/P4w4N61cRXoLbdj X4ApTRkPcK1DqcgVk8OIhGbXpDNmDAFhHpVrTPx6c2eXi0cQaRivBPKUxr4xWgSTiADj /sgRh8MoWwEPLYqce7wmFQIXV1AOuiE/KCDgy6Wm/BxfknHqmMPSU07AqkWiQ8qsSPRE FanuIb4OLTRK0XAQmMNJxZG9u9F8iAN6bgAXHCz2Ub8lXfMVk3ELcHuSbjoWKE/7uR37 DwfJgTfD/f4+tQebt1T7eaQrZYM3sx+BwhSb/5tXib0GkEPeqExsUkC6WstSJSYBsmMB 4dFA== MIME-Version: 1.0 X-Received: by 10.58.118.130 with SMTP id km2mr14970517veb.0.1377239278177; Thu, 22 Aug 2013 23:27:58 -0700 (PDT) Received: by 10.52.27.51 with HTTP; Thu, 22 Aug 2013 23:27:58 -0700 (PDT) In-Reply-To: <201308221408.08203.jhb@freebsd.org> References: <201308211401.46468.jhb@freebsd.org> <201308221408.08203.jhb@freebsd.org> Date: Fri, 23 Aug 2013 10:27:58 +0400 Message-ID: Subject: Re: Question about socket timeouts From: Vitja Makarov To: John Baldwin , freebsd-current@freebsd.org Content-Type: multipart/mixed; boundary=089e013a05acf25bb004e4978110 X-Mailman-Approved-At: Fri, 23 Aug 2013 11:26:06 +0000 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Aug 2013 06:27:59 -0000 --089e013a05acf25bb004e4978110 Content-Type: text/plain; charset=ISO-8859-1 2013/8/22 John Baldwin : > On Thursday, August 22, 2013 12:18:48 am Vitja Makarov wrote: >> 2013/8/21 John Baldwin : >> > On Monday, August 19, 2013 11:13:02 pm Daniel Eischen wrote: >> >> On Mon, 19 Aug 2013, Adrian Chadd wrote: >> >> >> >> > Yes! Please file a PR! >> >> >> >> This sorta implies that both are acceptable (although, >> >> the Linux behavior seems more desirable). >> >> >> >> http://austingroupbugs.net/view.php?id=369 >> > >> > No, that says "round up", so it does mean that the requested timeout >> > should be the minimum amount slept. tvtohz() does this. Really odd >> > that the socket code is using its own version of this rather than >> > tvtohz(). >> > >> > Oh, I bet this just predates tvtohz(). Interesting that it keeps getting >> > bug fixes in its history that simply using tvtohz() would have solved. >> > >> > Try this: >> > >> > Index: uipc_socket.c >> > =================================================================== >> > --- uipc_socket.c (revision 254570) >> > +++ uipc_socket.c (working copy) >> > @@ -2699,21 +2699,16 @@ sosetopt(struct socket *so, struct sockopt *sopt) >> > if (error) >> > goto bad; >> > >> > - /* assert(hz > 0); */ >> > if (tv.tv_sec < 0 || tv.tv_sec > INT_MAX / hz || >> > tv.tv_usec < 0 || tv.tv_usec >= 1000000) { >> > error = EDOM; >> > goto bad; >> > } >> > - /* assert(tick > 0); */ >> > - /* assert(ULONG_MAX - INT_MAX >= 1000000); */ >> > - val = (u_long)(tv.tv_sec * hz) + tv.tv_usec / tick; >> > - if (val > INT_MAX) { >> > + val = tvtohz(&tv); >> > + if (val == INT_MAX) { >> > error = EDOM; >> > goto bad; >> > } >> > - if (val == 0 && tv.tv_usec != 0) >> > - val = 1; >> > >> > switch (sopt->sopt_name) { >> > case SO_SNDTIMEO: >> > >> >> That must help. But I want to see the issue solved in the next >> release. I can't apply patch to the production system. Btw in >> production environment we have kern.hz set to 1000 so it's not a >> problem there. > > Can you test this in some way in a test environment? > Ok, sorry for posting out of the list. Simple test program is attached. Without your patch timeout expires in about 20ms. With it it's ~40ms. 40 instead of 30 is beacuse of odd tick added by tvtohz(). -- vitja. --089e013a05acf25bb004e4978110--