From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net [23.128.96.19]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 16D704A29 for ; Mon, 21 Aug 2023 10:18:37 +0000 (UTC) Received: from eu-smtp-delivery-151.mimecast.com (eu-smtp-delivery-151.mimecast.com [185.58.86.151]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D7198DC for ; Mon, 21 Aug 2023 03:18:35 -0700 (PDT) Received: from AcuMS.aculab.com (156.67.243.121 [156.67.243.121]) by relay.mimecast.com with ESMTP with both STARTTLS and AUTH (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id uk-mta-309-wqiF68MgN6SF-J6xIfBlHw-1; Mon, 21 Aug 2023 11:18:26 +0100 X-MC-Unique: wqiF68MgN6SF-J6xIfBlHw-1 Received: from AcuMS.Aculab.com (10.202.163.6) by AcuMS.aculab.com (10.202.163.6) with Microsoft SMTP Server (TLS) id 15.0.1497.48; Mon, 21 Aug 2023 11:18:14 +0100 Received: from AcuMS.Aculab.com ([::1]) by AcuMS.aculab.com ([::1]) with mapi id 15.00.1497.048; Mon, 21 Aug 2023 11:18:14 +0100 From: David Laight To: 'Kees Cook' , Jeff Layton CC: Andrew Morton , Jann Horn , "linux-hardening@vger.kernel.org" , "Elena Reshetova" , David Windsor , Hans Liljestrand , Trond Myklebust , Anna Schumaker , "Chuck Lever" , Neil Brown , Olga Kornievskaia , Dai Ngo , Tom Talpey , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Sergey Senozhatsky , "Alexey Gladkov" , "Eric W. Biederman" , "Yu Zhao" , "linux-kernel@vger.kernel.org" , "linux-nfs@vger.kernel.org" , "netdev@vger.kernel.org" Subject: RE: [PATCH v2] creds: Convert cred.usage to refcount_t Thread-Topic: [PATCH v2] creds: Convert cred.usage to refcount_t Thread-Index: AQHZ0hIjCu0dtWFxxUKez0i3A14O7q/0jIjg Date: Mon, 21 Aug 2023 10:18:13 +0000 Message-ID: References: <20230818041740.gonna.513-kees@kernel.org> <20230818105542.a6b7c41c47d4c6b9ff2e8839@linux-foundation.org> <202308181146.465B4F85@keescook> <20230818123148.801b446cfdbd932787d47612@linux-foundation.org> <202308181317.66E6C9A5@keescook> In-Reply-To: <202308181317.66E6C9A5@keescook> Accept-Language: en-GB, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.202.205.107] Precedence: bulk X-Mailing-List: netdev@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: aculab.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,PDS_BAD_THREAD_QP_64, RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H5,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE, SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net From: Kees Cook > Sent: Friday, August 18, 2023 9:25 PM >=20 > On Fri, Aug 18, 2023 at 04:10:49PM -0400, Jeff Layton wrote: > > [...] > > extra checks (supposedly) compile down to nothing. It should be possibl= e > > to build alternate refcount_t handling functions that are just wrappers > > around atomic_t with no extra checks, for folks who want to really run > > "fast and loose". >=20 > No -- there's no benefit for this. We already did all this work years > ago with the fast vs full break-down. All that got tossed out since it > didn't matter. We did all the performance benchmarking and there was no > meaningful difference -- refcount _is_ atomic with an added check that > is branch-predicted away. Hmmm IIRC recent Intel x86 cpu never do static branch prediction. So you can't avoid mis-predicted branches in cold code. =09David > Peter Zijlstra and Will Deacon spent a lot of > time making it run smoothly. :) >=20 > -Kees >=20 > -- > Kees Cook - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1= PT, UK Registration No: 1397386 (Wales)