Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754922AbdCTPGU convert rfc822-to-8bit (ORCPT ); Mon, 20 Mar 2017 11:06:20 -0400 Received: from smtp-out4.electric.net ([192.162.216.184]:51668 "EHLO smtp-out4.electric.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755017AbdCTPFF (ORCPT ); Mon, 20 Mar 2017 11:05:05 -0400 From: David Laight To: "'Peter Zijlstra'" CC: "'Herbert Xu'" , David Miller , "eric.dumazet@gmail.com" , "elena.reshetova@intel.com" , "keescook@chromium.org" , "netdev@vger.kernel.org" , "bridge@lists.linux-foundation.org" , "linux-kernel@vger.kernel.org" , "kuznet@ms2.inr.ac.ru" , "jmorris@namei.org" , "kaber@trash.net" , "stephen@networkplumber.org" , "ishkamiel@gmail.com" , "dwindsor@gmail.com" , "akpm@linux-foundation.org" Subject: RE: [PATCH 07/17] net: convert sock.sk_refcnt from atomic_t to refcount_t Thread-Topic: [PATCH 07/17] net: convert sock.sk_refcnt from atomic_t to refcount_t Thread-Index: AQHSoX+uGs2em8L41kmtByMJ2iW25KGdwQxggAAIV4CAAAYt4A== Date: Mon, 20 Mar 2017 15:00:33 +0000 Message-ID: <063D6719AE5E284EB5DD2968C1650D6DCFFB5570@AcuExch.aculab.com> References: <1489767196.28631.305.camel@edumazet-glaptop3.roam.corp.google.com> <20170318164759.GA23837@gondor.apana.org.au> <20170318.182121.439615057765380575.davem@davemloft.net> <20170320103937.lq7nfnutupr3gkn7@hirez.programming.kicks-ass.net> <20170320131629.GA26405@gondor.apana.org.au> <063D6719AE5E284EB5DD2968C1650D6DCFFB5483@AcuExch.aculab.com> <20170320142807.mhu3xod2x2zzvego@hirez.programming.kicks-ass.net> In-Reply-To: <20170320142807.mhu3xod2x2zzvego@hirez.programming.kicks-ass.net> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.202.99.200] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 8BIT MIME-Version: 1.0 X-Outbound-IP: 213.249.233.130 X-Env-From: David.Laight@ACULAB.COM X-Proto: esmtps X-Revdns: X-HELO: AcuExch.aculab.com X-TLS: TLSv1:AES128-SHA:128 X-Authenticated_ID: X-PolicySMART: 3396946, 3397078 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1165 Lines: 29 From: Peter Zijlstra > Sent: 20 March 2017 14:28 > On Mon, Mar 20, 2017 at 02:10:24PM +0000, David Laight wrote: > > On x86 the cpu flags from the 'lock inc/dec' could be used to reasonably > > cheaply detect errors - provided you actually generate a forwards branch. > > Note that currently there is no arch specific implementation. We could > of course cure this. > > But note that the thing you propose; using the overflow flag, can only > reasonably be done on PREEMPT=n kernels, otherwise we have an incredible > number of contexts that can nest. > > Sure; getting all starts aligned to double overflow is incredibly rare, > but I don't want to be the one to have to debug that. One overflow would set the overflow flag, you don't need both to fail. In any case you can use the sign flag. Say valid count values are -64k to -256 and 0 to MAXINT. The count will normally be +ve unless the 'main free path' has released the 64k references it holds. If the sign bit is set after inc/dec the value is checked; might valid, an error, or require the item be freed. Ok assuming the items have reasonable lifetimes and have a nominal 'delete' function. David