From owner-freebsd-current@FreeBSD.ORG Thu Feb 5 19:20:06 2015 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.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EAA72D00; Thu, 5 Feb 2015 19:20:05 +0000 (UTC) Received: from smtp2.wemm.org (smtp2.wemm.org [IPv6:2001:470:67:39d::78]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp2.wemm.org", Issuer "StartCom Class 1 Primary Intermediate Server CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id CD0D1C1A; Thu, 5 Feb 2015 19:20:05 +0000 (UTC) Received: from overcee.wemm.org (canning.wemm.org [192.203.228.65]) by smtp2.wemm.org (Postfix) with ESMTP id 954824AB; Thu, 5 Feb 2015 11:20:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wemm.org; s=m20140428; t=1423164005; bh=eXLWDGya+qs/d+L0zV69lILVrQJ5XxwaLZoVOWF5fhU=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=KrVU8PpHyGiv5hZg0mMrgJoh17H/3qMYnucraQIVmrGTg6rja72wOWMrQZ0G6+bSJ CWDZ4MbZalwUNWVaMO0THiyZCNsSYinMlEUY778P7FCPE6/o0yF3c6pBtJOuROfo2u ULdXRbVypG7/RRkGSykHrk7y71/HuUc39rTNkIEk= From: Peter Wemm To: freebsd-current@freebsd.org Subject: Re: PSA: If you run -current, beware! Date: Thu, 05 Feb 2015 11:20:01 -0800 Message-ID: <2082091.ZYtQ1zroo8@overcee.wemm.org> User-Agent: KMail/4.14.2 (FreeBSD/11.0-CURRENT; KDE/4.14.2; amd64; ; ) In-Reply-To: <14095201.eEMelRF1IS@overcee.wemm.org> References: <8089702.oYScRm8BTN@overcee.wemm.org> <8273349.HE1luBF2tk@ralph.baldwin.cx> <14095201.eEMelRF1IS@overcee.wemm.org> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1943395.5bLfEGhhdO"; micalg="pgp-sha256"; protocol="application/pgp-signature" Cc: Konstantin Belousov , Luigi Rizzo X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 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: Thu, 05 Feb 2015 19:20:06 -0000 --nextPart1943395.5bLfEGhhdO Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="us-ascii" On Thursday, February 05, 2015 11:00:46 AM Peter Wemm wrote: > On Thursday, February 05, 2015 10:48:54 AM John Baldwin wrote: > > On Thursday, February 05, 2015 04:22:23 PM Luigi Rizzo wrote: > > > On Thu, Feb 05, 2015 at 08:21:45AM -0500, John Baldwin wrote: > > > > On Thursday, February 05, 2015 08:48:33 AM Luigi Rizzo wrote: > > > ... > > >=20 > > > > > > > It is fixed (in the proper meaning of the word, not like = worked > > > > > > > around, > > > > > > > covered by paper) by the patch at the end of the mail. > > > > > > >=20 > > > > > > > We already have a story trying to enable much less ambiti= ous > > > > > > > option > > > > > > > -fno-strict-overflow, see r259045 and the revert in r2594= 22. I > > > > > > > do > > > > > > > not > > > > > > > see other way than try one more time. Too many places in= kernel > > > > > > > depend on the correctly wrapping 2-complement arithmetic,= among > > > > > > > others > > > > > > > are callweel and scheduler. > > > > >=20 > > > > > Rather than depending on a compiler option, wouldn't it be > > > > > better/more > > > > > robust to change ticks to unsigned, which has specified wrapp= ing > > > > > behavior? > > > >=20 > > > > Yes, but non-trivial. It's also not limited to ticks. Since t= he > > > > compiler > > > > knows when it would apply these optimizations, it would be nice= if it > > > > could > > > > warn instead (GCC apparently has a warning, but clang does not)= .=20 > > > > Having > > > > people do a manual audit of every signed integer expression in = the > > > > tree > > > > will take a long time. > > >=20 > > > I think I misunderstood the problem as being limited to ticks, > > > which is probably only one symptom of a fundamental change in beh= aviour > > > of the compiler. > > > Still, it might be worthwhile start looking at ints that ought to= be > > > implemented as u_int > >=20 > > I actually agree, I just think we are stuck with -fwrapv in the int= erval, > > but it's probably not a short interval. I think converting ticks t= o > > unsigned would be a good first start. >=20 > For the record, I agree. However, I suspect that attempts to do so w= ill > have a non trivial number of bugs introduced. We have a track record= of > recurring problems with tcp sequence number space arithmetic and tcp > timing, partly because the wraparounds happens infrequently. BTW; anybody working on this will want to run with kern.hz=3D"100000" = in=20 loader.conf (or higher). Having the clock tick 100 times faster speeds= the=20 rollover up from every ~25 days to every ~6 hours. I don't know what t= he=20 practical limit is but at some point it will cause sufficient pain due = to=20 contention that it won't be useful. =2D-=20 Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com; KI= 6FJV UTF-8: for when a ' or ... just won\342\200\231t do\342\200\246 --nextPart1943395.5bLfEGhhdO Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAABCAAGBQJU08JhAAoJEDXWlwnsgJ4EFpMIANIQPgj0aqZ/ul32WsXUJPrt qz1qkeL6eOC1cP2GQdkGOHY99voNY7CLcvoAqGFsGO/VTLGqKbjoNQhvX3Mn9zTx lMYVAUvQiC0XJLH+HG92ZPEhDpFSRcYyti4DZdrCj018eAA6b95UDe36ee0C37jl Rmtu2zEV/qPVtr1iwgFY6XEi5qZaiXfVGIjvEZy0RRX2cgvZJEvIkm44Bgf3zoFo dZw1ttz8p9lB67TKCuhRUA3OE7MnnwITI2Ak9nqXOTwc5Nbnzc/dB7fGDe2NVGPt nA2FvqfGGTmfSLXFB3AC99U6QRJrXeVUp/t2otRIi9w0hPZB2HIhXq8Gtt20daI= =99Le -----END PGP SIGNATURE----- --nextPart1943395.5bLfEGhhdO--