[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <201906150654.FF4400F7C8@keescook>
Date: Sat, 15 Jun 2019 06:59:33 -0700
From: Kees Cook <keescook@...omium.org>
To: Ard Biesheuvel <ard.biesheuvel@...aro.org>
Cc: Will Deacon <will.deacon@....com>,
Jayachandran Chandrasekharan Nair <jnair@...vell.com>,
"catalin.marinas@....com" <catalin.marinas@....com>,
Jan Glauber <jglauber@...vell.com>,
Linus Torvalds <torvalds@...ux-foundation.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-arm-kernel@...ts.infradead.org"
<linux-arm-kernel@...ts.infradead.org>
Subject: Re: [RFC] Disable lockref on arm64
On Sat, Jun 15, 2019 at 10:47:19AM +0200, Ard Biesheuvel wrote:
> remaining question Will had was whether it makes sense to do the
> condition checks before doing the actual store, to avoid having a time
> window where the refcount assumes its illegal value. Since arm64 does
> not have memory operands, the instruction count wouldn't change, but
> it will definitely result in a performance hit on out-of-order CPUs.
What do the races end up looking like? Is it possible to have two
threads ordered in a way that a second thread could _un_saturate a
counter?
CPU 1 CPU 2
inc()
load INT_MAX-1
about to overflow?
yes
dec()
load INT_MAX-1
set to INT_MAX
set to INT_MAX-2
Or would you use the same INT_MIN/2 saturation point done on x86?
As for performance, it should be easy to measure with the LKDTM test
to find out exactly the differences.
--
Kees Cook
Powered by blists - more mailing lists