From owner-svn-src-all@FreeBSD.ORG Thu Apr 2 14:23:24 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 5B45B819; Thu, 2 Apr 2015 14:23:24 +0000 (UTC) Received: from mail-wg0-x229.google.com (mail-wg0-x229.google.com [IPv6:2a00:1450:400c:c00::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D6DF1C49; Thu, 2 Apr 2015 14:23:23 +0000 (UTC) Received: by wgbdm7 with SMTP id dm7so87178012wgb.1; Thu, 02 Apr 2015 07:23:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=IWubHRkQ9yeUXh5XxE0jIFXrg70BGUeFeiw7yy1YcT8=; b=MfxpY9KrDn6j4XEIpUQOS6vGDjrckXfy7BHFGHtWZNBi4Acw4ZmzK70H/Amw3xkSF8 qz/M2qX1AeGN4tyH1qC43SK5uwNdYUQAtdJU9L5sDvjZwH3T4GJLm4u8Gt2vnMjfAfU1 Buf4y+YjE4raN6dwKBtuAN6J68RXcgFrxC2zzWENm4PHg5M7EULC2g4Y2q9rD905Ws+j in0PUBLe3jFn+FY/nuUPZvUriNk7z21kASrcna+pLJs8K9Tnwhqvhw2dF1TKunlUbZib oJnmqAI9r808CmmfCitrtJl+/vwglwXhwIOV/Pbe7WPF46ccz8XM7iaByFCzFiFQvmdK FuGg== X-Received: by 10.194.47.201 with SMTP id f9mr92486629wjn.17.1427984601958; Thu, 02 Apr 2015 07:23:21 -0700 (PDT) Received: from dft-labs.eu (n1x0n-1-pt.tunnel.tserv5.lon1.ipv6.he.net. [2001:470:1f08:1f7::2]) by mx.google.com with ESMTPSA id bp1sm7472205wjb.31.2015.04.02.07.23.20 (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Thu, 02 Apr 2015 07:23:21 -0700 (PDT) Date: Thu, 2 Apr 2015 16:23:18 +0200 From: Mateusz Guzik To: Ian Lepore Subject: Re: svn commit: r280971 - in head: contrib/ipfilter/tools share/man/man4 sys/contrib/ipfilter/netinet sys/netinet sys/netipsec sys/netpfil/pf Message-ID: <20150402142318.GC549@dft-labs.eu> References: <201504012226.t31MQedN044443@svn.freebsd.org> <1427929676.82583.103.camel@freebsd.org> <20150402123522.GC64665@FreeBSD.org> <20150402133751.GA549@dft-labs.eu> <20150402134217.GG64665@FreeBSD.org> <20150402135157.GB549@dft-labs.eu> <1427983109.82583.115.camel@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <1427983109.82583.115.camel@freebsd.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, Gleb Smirnoff , src-committers@freebsd.org 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: Thu, 02 Apr 2015 14:23:24 -0000 On Thu, Apr 02, 2015 at 07:58:29AM -0600, Ian Lepore wrote: > On Thu, 2015-04-02 at 15:51 +0200, Mateusz Guzik wrote: > > On Thu, Apr 02, 2015 at 04:42:17PM +0300, Gleb Smirnoff wrote: > > > On Thu, Apr 02, 2015 at 03:37:51PM +0200, Mateusz Guzik wrote: > > > M> For this particular use-case you never care what CPU you are executing > > > M> on, you only want to obtain a unique number. > > > M> > > > M> per-cpu counters can serve this purpose no problem, just provide an > > > M> operation which guarantees to return the new value of the counter it > > > M> incremented. Should be easily achieved with e.g. just pinning curthread > > > M> to the cpu it executes on for the duration of inc + fetch. > > > > > > I'd ask to pay attention to this particular email: > > > > > > https://lists.freebsd.org/pipermail/svn-src-head/2015-March/069966.html > > > > > > Just to justify probabilities, risks and countermeasures. > > > > > > For those, who don't believe in theory and prefers practice: > > > > > > https://lists.freebsd.org/pipermail/svn-src-head/2015-March/070091.html > > > > > > Note that Emeric was the one who observed collisions for the ip_id++ > > > code, that we used before. > > > > > > > Well in that case this at least deserves a comment in the code. Everyone > > spotting that counter_u64_add + zpcpu_get will think it's a bug. > > > > Because it IS a bug. That isn't changed by the fact that it works > reliably on one platform due to what should be an opque implementation > detail, and works by accident on other platforms (at least until the > details of their implementations change in the future). > > As soon as somebody sees this code, thinks it's a good way to do things, > and cut and pastes it into another venue and removes the & 0xffff, it > just turns into a bug on every platform except amd64. > Well, a thread migrating to another cpu is the standard thing everyone sees. Are you referring to the fact that the counter is 64-bit, so 32-bit arches must perform 2 reads and the thread can be migrated in-between? Indeed that would look like a solid problem, mitigated 'by accident' with 0xffff. I don't feel that strongly about changing the code. If it stays as it is, it definitely needs the comment I mentioned explaining why migration is fine. If the code was to be changed a machdep counter_u64_fetchadd seems like the only course of action. -- Mateusz Guzik