From owner-svn-src-all@FreeBSD.ORG Sun Mar 29 21:08:09 2015 Return-Path: Delivered-To: svn-src-all@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 16D14DEA; Sun, 29 Mar 2015 21:08:09 +0000 (UTC) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.69.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "cell.glebius.int.ru", Issuer "cell.glebius.int.ru" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 728249DE; Sun, 29 Mar 2015 21:08:07 +0000 (UTC) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.9/8.14.9) with ESMTP id t2TL7vR2039693 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 30 Mar 2015 00:07:57 +0300 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.9/8.14.9/Submit) id t2TL7vFk039692; Mon, 30 Mar 2015 00:07:57 +0300 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Mon, 30 Mar 2015 00:07:57 +0300 From: Gleb Smirnoff To: Adrian Chadd Subject: Re: svn commit: r280759 - head/sys/netinet Message-ID: <20150329210757.GA64665@FreeBSD.org> References: <201503271326.t2RDQxd3056112@svn.freebsd.org> <20150328083443.GV64665@FreeBSD.org> <20150328191629.GY64665@FreeBSD.org> <5517B433.5010508@selasky.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Cc: Hans Petter Selasky , "svn-src-head@freebsd.org" , "svn-src-all@freebsd.org" , "src-committers@freebsd.org" , Fabien Thomas X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Mar 2015 21:08:09 -0000 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. So, to conclude: yes, there is a race. Its probability is extremely low, and hitting the race leads to an event that already happens orders of magnitude more enough, than the race would happen. -- Totus tuus, Glebius.