Date: Sun, 29 Mar 2015 15:56:22 -0600 From: Ian Lepore <ian@freebsd.org> To: Gleb Smirnoff <glebius@FreeBSD.org> Cc: Hans Petter Selasky <hps@selasky.org>, Adrian Chadd <adrian@freebsd.org>, "src-committers@freebsd.org" <src-committers@freebsd.org>, "svn-src-all@freebsd.org" <svn-src-all@freebsd.org>, "svn-src-head@freebsd.org" <svn-src-head@freebsd.org>, Fabien Thomas <fabient@freebsd.org> Subject: Re: svn commit: r280759 - head/sys/netinet Message-ID: <1427666182.82583.4.camel@freebsd.org> 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> <CAJ-VmonU15_nEGVQNwR52deDf1TbPUz0oAMr%2B3zwNqU_9%2Bo1fw@mail.gmail.com> <20150329210757.GA64665@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <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.
>
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1427666182.82583.4.camel>