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.