From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933707AbcIEPEX (ORCPT ); Mon, 5 Sep 2016 11:04:23 -0400 Received: from smtp-out6.electric.net ([192.162.217.181]:57623 "EHLO smtp-out6.electric.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932605AbcIEPEV (ORCPT ); Mon, 5 Sep 2016 11:04:21 -0400 From: David Laight To: "'David Howells'" , "netdev@vger.kernel.org" CC: "linux-afs@lists.infradead.org" , "linux-kernel@vger.kernel.org" Subject: RE: [PATCH net-next 4/9] rxrpc: Randomise epoch and starting client conn ID values Thread-Topic: [PATCH net-next 4/9] rxrpc: Randomise epoch and starting client conn ID values Thread-Index: AQHSBvDDU0yrSbsNE0OESi011ImrZqBq/RFg Date: Mon, 5 Sep 2016 15:01:40 +0000 Message-ID: <063D6719AE5E284EB5DD2968C1650D6DB00F48DE@AcuExch.aculab.com> References: <147302294435.28597.15007422228950187972.stgit@warthog.procyon.org.uk> <147302297165.28597.8317497494192917329.stgit@warthog.procyon.org.uk> In-Reply-To: <147302297165.28597.8317497494192917329.stgit@warthog.procyon.org.uk> 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="utf-8" 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-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by mail.home.local id u85F4SuQ000592 From: David Howells > Sent: 04 September 2016 22:03 > Create a random epoch value rather than a time-based one on startup and set > the top bit to indicate that this is the case. Why set the top bit? There is nothing to stop the time (in seconds) from having the top bit set. Nothing else can care - otherwise this wouldn't work. > Also create a random starting client connection ID value. This will be > incremented from here as new client connections are created. I'm guessing this is to make duplicates less likely after a restart? You may want to worry about duplicate allocations (after 2^32 connects). There are id allocation algorithms that guarantee not to generate duplicates and not to reuse values quickly while still being fixed cost. Look at the code NetBSD uses to allocate process ids for an example. David