[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 19 Jan 2017 13:52:47 +0100
From: Peter Zijlstra <peterz@...radead.org>
To: "Reshetova, Elena" <elena.reshetova@...el.com>
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."
> This had numbers on addl vs. cmpxchg:
> http://www.openwall.com/lists/kernel-hardening/2016/10/04/10
http://lkml.kernel.org/r/20161111102913.GE3117@twins.programming.kicks-ass.net
does too, sure cmpxchg is a bit slower uncontended, but I'm not sure we
should worry about that much. And refcounts really should not be heavily
contended, if they are there's design level issues that ought to be
looked at.
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.
