On Mon, Apr 24, 2017 at 4:00 AM, PaX Team <pageexec@xxxxxxxxxxx> wrote: > On 24 Apr 2017 at 10:32, Peter Zijlstra wrote: > >> On Fri, Apr 21, 2017 at 03:09:39PM -0700, Kees Cook wrote: >> > This patch ports the x86-specific atomic overflow handling from PaX's >> > PAX_REFCOUNT to the upstream refcount_t API. This is an updated version >> > from PaX that eliminates the saturation race condition by resetting the >> > atomic counter back to the INT_MAX saturation value on both overflow and >> > underflow. To win a race, a system would have to have INT_MAX threads >> > simultaneously overflow before the saturation handler runs. > > note that the above is wrong (and even contradicting itself and the code). True, this changelog could be more accurate (it resets to INT_MAX on overflow and INT_MIN on underflow). I think I'm right in saying that a system would need INT_MAX threads running a refcount_inc() (and a refcount_dec_and_test() at exactly the right moment) before the reset handler got scheduled, though, yes? I'll attempt to clarify this. -Kees -- Kees Cook Pixel Security
