linux-kernel - Re: [PATCH v11 1/3] ipc: Allow boot time extension of IPCMNI from 32k to 16M

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <f9e476ce-9381-3738-159d-2c555580961a@colorfullife.com>
Date:   Tue, 20 Nov 2018 20:45:18 +0100
From:   Manfred Spraul <manfred@...orfullife.com>
To:     Waiman Long <longman@...hat.com>,
        "Luis R. Rodriguez" <mcgrof@...nel.org>,
        Kees Cook <keescook@...omium.org>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Jonathan Corbet <corbet@....net>
Cc:     linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org,
        linux-doc@...r.kernel.org, Al Viro <viro@...iv.linux.org.uk>,
        Matthew Wilcox <willy@...radead.org>,
        "Eric W. Biederman" <ebiederm@...ssion.com>,
        Takashi Iwai <tiwai@...e.de>, Davidlohr Bueso <dbueso@...e.de>
Subject: Re: [PATCH v11 1/3] ipc: Allow boot time extension of IPCMNI from 32k
 to 16M

On 11/9/18 9:11 PM, 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 16M. This
> is a 512X increase which should be big enough for users out there that
> need a large number of unique IPC identifier.
>
> 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.
>
> This new option does have the side effect of reducing the maximum number
> of unique sequence numbers from 64k down to 128. So it is a trade-off.
>
> The computation of a new IPC id is not done in the performance critical
> path.  So a little bit of additional overhead shouldn't have any real
> performance impact.
>
> Signed-off-by: Waiman Long <longman@...hat.com>
Acked-by: Manfred Spraul <manfred@...orfullife.com>