On Mon, Nov 05, 2018 at 10:43:43AM -0500, Waiman Long wrote:

The maximum number of unique System V IPC identifiers was limited to
32k.  That limit should be big enough for most use cases.

However, there are some users out there requesting for more, especially
those that are migrating from Solaris which uses 24 bits for unique
identifiers. To satisfy the need of those users, a new boot time kernel
option "ipcmni_extend" is added to extend the IPCMNI value to 8M. This
is a 256X increase which hopefully is big enough for them.

Why go to 23 bits when people are coming from systems with 24 bits?
Let's just go to 24 bits.  This happens to fit well with the underlying
data structure which uses 6 bits per layer of the tree.

The use of this new option will change the pattern of the IPC identifiers
returned by functions like shmget(2). An application that depends on
such pattern may not work properly.  So it should only be used if the
users really need more than 32k of unique IPC numbers.

Are there applications out there that rely on the internal structure of
the IPC identifiers?!

How about scrapping all this and just doing the following:

Allocate 24 bits of the ID cyclically.  Increment the top 7 bits of the
ID every time the cursor wraps.  That's not going to give us a perfect
progression from 0-2 billion, because it'll skip the ones in use.
But it'll ensure the ID isn't reused particularly quickly unless the
application is really using millions of IDs.