Date: Mon, 30 Mar 2015 00:07:57 +0300 From: Gleb Smirnoff <glebius@FreeBSD.org> To: Adrian Chadd <adrian@freebsd.org> Cc: Hans Petter Selasky <hps@selasky.org>, "svn-src-head@freebsd.org" <svn-src-head@freebsd.org>, "svn-src-all@freebsd.org" <svn-src-all@freebsd.org>, "src-committers@freebsd.org" <src-committers@freebsd.org>, Fabien Thomas <fabient@freebsd.org> Subject: Re: svn commit: r280759 - head/sys/netinet Message-ID: <20150329210757.GA64665@FreeBSD.org> In-Reply-To: <CAJ-VmonU15_nEGVQNwR52deDf1TbPUz0oAMr%2B3zwNqU_9%2Bo1fw@mail.gmail.com> References: <201503271326.t2RDQxd3056112@svn.freebsd.org> <20150328083443.GV64665@FreeBSD.org> <20150328191629.GY64665@FreeBSD.org> <5517B433.5010508@selasky.org> <CAJ-VmonU15_nEGVQNwR52deDf1TbPUz0oAMr%2B3zwNqU_9%2Bo1fw@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, Mar 29, 2015 at 08:16:46AM -0700, Adrian Chadd wrote:
A> On 29 March 2015 at 01:13, Hans Petter Selasky <hps@selasky.org> 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20150329210757.GA64665>