Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 19 Jan 2017 14:15:36 +0000
From: "Reshetova, Elena" <>
To: Peter Zijlstra <>
CC: Eric Biggers <>, ""
	<>, ""
	<>, "" <>,
	"" <>, ""
	<>, "Anvin, H Peter" <>,
	"" <>, ""
	<>, ""
Subject: RE: [RFCv2 PATCH 00/18] refcount_t API + usage

> On Thu, Jan 19, 2017 at 10:22:28AM +0000, Reshetova, Elena wrote:
> > > You again failed to reply to my last email on the subject. The initial
> > > PaX thing was broken as heck, only later did you mention it got fixed. I
> > > told you we could change to that for x86 if it could be proven to be
> > > equivalent.
> >
> > I am confused on what is referred here as a fix..
> From where Eric said:
> "I do see they used to use a slightly different approach that did a decrement
> instead of setting the counter to INT_MAX.  And that was clearly racy because
> two concurrent increments could circumvent the overflow protection."

Oh, now I understand. I somehow missed this in the previous discussion, sorry about this. 
Thanks for explaining!
So, yes, I guess this is a cheap (performance wise) way to fix the race without using cmpxchg, but
I guess this has the same issue you didn't like in it before: it ends up being not atomic when protection kicks in. 
Whenever this a real issue or not, I am not so sure... 

Best Regards,

Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.