|
Message-ID: <2236FBA76BA1254E88B949DDB74E612B41C3F2B3@IRSMSX102.ger.corp.intel.com> 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.