From owner-svn-src-head@FreeBSD.ORG Sun Mar 29 21:56:36 2015 Return-Path: Delivered-To: svn-src-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 24397855; Sun, 29 Mar 2015 21:56:36 +0000 (UTC) Received: from relay.mailchannels.net (tkt-001-i354.relay.mailchannels.net [174.136.5.215]) by mx1.freebsd.org (Postfix) with ESMTP id 28826F35; Sun, 29 Mar 2015 21:56:32 +0000 (UTC) X-Sender-Id: duocircle|x-authuser|hippie Received: from smtp4.ore.mailhop.org (ip-10-220-9-73.us-west-2.compute.internal [10.220.9.73]) by relay.mailchannels.net (Postfix) with ESMTPA id BA3011002A0; Sun, 29 Mar 2015 21:56:24 +0000 (UTC) X-Sender-Id: duocircle|x-authuser|hippie Received: from smtp4.ore.mailhop.org (smtp4.ore.mailhop.org [10.21.145.197]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:2500 (trex/5.4.8); Sun, 29 Mar 2015 21:56:25 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: duocircle|x-authuser|hippie X-MailChannels-Auth-Id: duocircle X-MC-Loop-Signature: 1427666184886:1697215896 X-MC-Ingress-Time: 1427666184886 Received: from c-73-34-117-227.hsd1.co.comcast.net ([73.34.117.227] helo=ilsoft.org) by smtp4.ore.mailhop.org with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.82) (envelope-from ) id 1YcLBu-0001nl-QB; Sun, 29 Mar 2015 21:56:23 +0000 Received: from revolution.hippie.lan (revolution.hippie.lan [172.22.42.240]) by ilsoft.org (8.14.9/8.14.9) with ESMTP id t2TLuM2G055133; Sun, 29 Mar 2015 15:56:22 -0600 (MDT) (envelope-from ian@freebsd.org) X-Mail-Handler: DuoCircle Outbound SMTP X-Originating-IP: 73.34.117.227 X-Report-Abuse-To: abuse@duocircle.com (see https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information for abuse reporting information) X-MHO-User: U2FsdGVkX19v53RfpMtik2/g8FfWUhod Message-ID: <1427666182.82583.4.camel@freebsd.org> Subject: Re: svn commit: r280759 - head/sys/netinet From: Ian Lepore To: Gleb Smirnoff Date: Sun, 29 Mar 2015 15:56:22 -0600 In-Reply-To: <20150329210757.GA64665@FreeBSD.org> References: <201503271326.t2RDQxd3056112@svn.freebsd.org> <20150328083443.GV64665@FreeBSD.org> <20150328191629.GY64665@FreeBSD.org> <5517B433.5010508@selasky.org> <20150329210757.GA64665@FreeBSD.org> Content-Type: text/plain; charset="us-ascii" X-Mailer: Evolution 3.12.10 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-AuthUser: hippie Cc: Hans Petter Selasky , Adrian Chadd , "src-committers@freebsd.org" , "svn-src-all@freebsd.org" , "svn-src-head@freebsd.org" , Fabien Thomas X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.18-1 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: Sun, 29 Mar 2015 21:56:36 -0000 On Mon, 2015-03-30 at 00:07 +0300, Gleb Smirnoff wrote: > On Sun, Mar 29, 2015 at 08:16:46AM -0700, Adrian Chadd wrote: > A> On 29 March 2015 at 01:13, Hans Petter Selasky wrote: > A> > On 03/28/15 20:16, Gleb Smirnoff wrote: > A> >> > A> >> +uint16_t > A> >> +ip_newid(void) > A> >> +{ > A> >> + > A> >> + counter_u64_add(V_ip_id, 1); > A> >> + return (htons((*(uint64_t *)zpcpu_get(V_ip_id)) & 0xffff)); > A> >> +} > A> > > A> > > A> > Technically you would need to enter a critical section here, so that the > A> > current process doesn't get swapped to a different CPU between the counter > A> > add and the zpcpu_get. > A> > A> +10000 here. > A> > A> You can get preempted and shifted to another CPU at almost any point > A> in time you're not explicitly asking not to be. It's.. frustrating. > > What happens in case of the race is that one CPU will use counter of the > other CPU, reusing the ID that was just used by the other CPU. And this > isn't a fatal race, it is just reuse of ID. The probability of such event > is much lower than probability of a collision due to overflowing uint16_t. > > For example, if we emit 1 Mpps, then we overflow the ID counter 15 times > per second. Every ID is reused 15 times within this small interval of time, > which of course is larger than TTL. And we find this kinda acceptable. > > To illustrate the probability of 1 instruction race, I would suggest to > look at PCPU_ADD() implementation for all arches except amd64/i386 and > find out that it is prone to this race. Hitting the race in PCPU_ADD() > will usually lead to mangling vm_meter statistics. Did we ever observe > this in practice? No. > I was under the impression that PCPU_ADD(), like all pcpu r-m-w accesses, requires the calling code to have taken steps to ensure the code doesn't migrate during the sequence. If callers aren't doing so, that seems like a bug in the calling code, not the PCPU_ADD() code. -- Ian