From owner-svn-src-head@freebsd.org Wed Oct 2 15:03:30 2019 Return-Path: Delivered-To: svn-src-head@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 0BC8213153B; Wed, 2 Oct 2019 15:03:30 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 46jzss4w5Tz4X9T; Wed, 2 Oct 2019 15:03:29 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id x92F3F3M050767 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Wed, 2 Oct 2019 18:03:19 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua x92F3F3M050767 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id x92F3Fdx050766; Wed, 2 Oct 2019 18:03:15 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 2 Oct 2019 18:03:15 +0300 From: Konstantin Belousov To: Ian Lepore Cc: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r352938 - head/sys/arm/include Message-ID: <20191002150315.GC44691@kib.kiev.ua> References: <201910011939.x91Jd0tK010821@repo.freebsd.org> <20191001194932.GZ44691@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.12.2 (2019-09-21) X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FROM, NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on tom.home X-Rspamd-Queue-Id: 46jzss4w5Tz4X9T X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-5.99 / 15.00]; NEURAL_HAM_MEDIUM(-0.99)[-0.993,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; REPLY(-4.00)[] X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.29 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: Wed, 02 Oct 2019 15:03:30 -0000 On Tue, Oct 01, 2019 at 01:53:05PM -0600, Ian Lepore wrote: > On Tue, 2019-10-01 at 22:49 +0300, Konstantin Belousov wrote: > > On Tue, Oct 01, 2019 at 07:39:00PM +0000, Ian Lepore wrote: > > > Author: ian > > > Date: Tue Oct 1 19:39:00 2019 > > > New Revision: 352938 > > > URL: https://svnweb.freebsd.org/changeset/base/352938 > > > > > > Log: > > > Add 8 and 16 bit versions of atomic_cmpset and atomic_fcmpset for arm. > > > > > > This adds 8 and 16 bit versions of the cmpset and fcmpset functions. Macros > > > are used to generate all the flavors from the same set of instructions; the > > > macro expansion handles the couple minor differences between each size > > > variation (generating ldrexb/ldrexh/ldrex for 8/16/32, etc). > > > > > > In addition to handling new sizes, the instruction sequences used for cmpset > > > and fcmpset are rewritten to be a bit shorter/faster, and the new sequence > > > will not return false when *dst==*old but the store-exclusive fails because > > > of concurrent writers. Instead, it just loops like ldrex/strex sequences > > > normally do until it gets a non-conflicted store. The manpage allows LL/SC > > > architectures to bogusly return false, but there's no reason to actually do > > > so, at least on arm. > > > > The reason is to avoid nested loops. The outer control for retry was the > > initial design decision for fcmpset() comparing to cmpset(). casueword() > > also started following this approach after the fixes for ll/sc looping > > after the external control. > > If the implementation is forbidden from looping, then the manpage > should say so. What I commited meets the requirements currently stated > in the manpage. Until somebody explains to me why it is somehow > harmful to return the RIGHT information at a cost of either 0 or 1 > extra cpu cycle, it's staying the way it is. Implementation is not forbidden from looping, but looping definitely deteriorates the quality of the implementation. Problem with the loop is that the outer caller does not have control over the inner loop, while it is the outer caller who knows more about terminating conditions. I can only point out casueword(9) where inner looping is causing CVE-level issues. I do not believe that any of atomic(9) primitives on ll/sc machines cause the CVE for us right now (but casueword did). Note that even x86 does not use the comparision with dest, but rely on the CPU flag to provide the result (this is the closest analog of not looping for CAS).