From: David Laight <David.Laight@ACULAB.COM>
To: "'David Howells'" <dhowells@redhat.com>,
"netdev@vger.kernel.org" <netdev@vger.kernel.org>
Cc: "linux-afs@lists.infradead.org" <linux-afs@lists.infradead.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: RE: [PATCH net-next 4/9] rxrpc: Randomise epoch and starting client conn ID values
Date: Mon, 5 Sep 2016 15:01:40 +0000 [thread overview]
Message-ID: <063D6719AE5E284EB5DD2968C1650D6DB00F48DE@AcuExch.aculab.com> (raw)
In-Reply-To: <147302297165.28597.8317497494192917329.stgit@warthog.procyon.org.uk>
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
next prev parent reply other threads:[~2016-09-05 15:04 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-09-04 21:02 [PATCH net-next 0/9] rxrpc: Small fixes David Howells
2016-09-04 21:02 ` [PATCH net-next 1/9] rxrpc: fix undefined behavior in rxrpc_mark_call_released David Howells
2016-09-04 21:02 ` [PATCH net-next 2/9] rxrpc: Fix uninitialised variable warning David Howells
2016-09-04 21:02 ` [PATCH net-next 3/9] rxrpc: The client call state must be changed before attachment to conn David Howells
2016-09-04 21:02 ` [PATCH net-next 4/9] rxrpc: Randomise epoch and starting client conn ID values David Howells
2016-09-05 15:01 ` David Laight [this message]
2016-09-05 16:24 ` David Howells
2016-09-06 2:12 ` Jeffrey Altman
2016-09-04 21:02 ` [PATCH net-next 5/9] rxrpc: Don't change the epoch David Howells
2016-09-04 21:03 ` [PATCH net-next 6/9] fs/afs/vlocation: Remove deprecated create_singlethread_workqueue David Howells
2016-09-04 21:03 ` [PATCH net-next 7/9] fs/afs/rxrpc: " David Howells
2016-09-04 21:03 ` [PATCH net-next 8/9] fs/afs/callback: " David Howells
2016-09-04 21:03 ` [PATCH net-next 9/9] fs/afs/flock: " David Howells
2016-09-06 20:53 ` [PATCH net-next 0/9] rxrpc: Small fixes David Miller
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=063D6719AE5E284EB5DD2968C1650D6DB00F48DE@AcuExch.aculab.com \
--to=david.laight@aculab.com \
--cc=dhowells@redhat.com \
--cc=linux-afs@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).