From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx1.redhat.com ([209.132.183.28]:45654 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725882AbeKIHHG (ORCPT ); Fri, 9 Nov 2018 02:07:06 -0500 Subject: Re: [PATCH v10 1/4] ipc: Allow boot time extension of IPCMNI from 32k to 8M To: Matthew Wilcox Cc: "Luis R. Rodriguez" , Kees Cook , Andrew Morton , Jonathan Corbet , linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-doc@vger.kernel.org, Al Viro , "Eric W. Biederman" , Takashi Iwai , Davidlohr Bueso , Manfred Spraul References: <1541432626-27780-1-git-send-email-longman@redhat.com> <1541432626-27780-2-git-send-email-longman@redhat.com> <20181106132059.GD3074@bombadil.infradead.org> From: Waiman Long Message-ID: Date: Thu, 8 Nov 2018 16:29:41 -0500 MIME-Version: 1.0 In-Reply-To: <20181106132059.GD3074@bombadil.infradead.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8BIT Content-Language: en-US Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On 11/06/2018 08:20 AM, Matthew Wilcox wrote: > 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. Sure. I can move it up to 24 bits leave 7 bits for the sequence number. > >> 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?! That is a question that may not have a clear answer. Most applications won't do that, but there are always some outliners that do crazy thing. So you never know for sure. > > 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. Eric Biederman had sent out a patch somewhat like that before. Again, there is a slight chance that it may break existing applications. So the question is whether we are willing to take the risk. I won't mind if upstream decide to go this route. Cheers, Longman