[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 19 Jan 2017 14:15:36 +0000
From: "Reshetova, Elena" <elena.reshetova@...el.com>
To: Peter Zijlstra <peterz@...radead.org>
CC: Eric Biggers <ebiggers3@...il.com>, "kernel-hardening@...ts.openwall.com"
<kernel-hardening@...ts.openwall.com>, "keescook@...omium.org"
<keescook@...omium.org>, "arnd@...db.de" <arnd@...db.de>,
"tglx@...utronix.de" <tglx@...utronix.de>, "mingo@...hat.com"
<mingo@...hat.com>, "Anvin, H Peter" <h.peter.anvin@...el.com>,
"will.deacon@....com" <will.deacon@....com>, "dwindsor@...il.com"
<dwindsor@...il.com>, "gregkh@...uxfoundation.org"
<gregkh@...uxfoundation.org>
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 http://lkml.kernel.org/r/20161230010627.GA9882@zzz 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,
Elena.
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.
