From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933732Ab2JYHxj (ORCPT ); Thu, 25 Oct 2012 03:53:39 -0400 Received: from relay.parallels.com ([195.214.232.42]:38233 "EHLO relay.parallels.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932829Ab2JYHxi convert rfc822-to-8bit (ORCPT ); Thu, 25 Oct 2012 03:53:38 -0400 Message-ID: <5088EFE6.2040900@parallels.com> Date: Thu, 25 Oct 2012 11:53:10 +0400 From: Stanislav Kinsbursky User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121011 Thunderbird/16.0.1 MIME-Version: 1.0 To: Andrew Morton CC: "serge.hallyn@canonical.com" , "ebiederm@xmission.com" , "linux-kernel@vger.kernel.org" , Pavel Emelianov , "catalin.marinas@arm.com" , "will.deacon@arm.com" , "jmorris@namei.org" , "cmetcalf@tilera.com" , "joe.korty@ccur.com" , "dhowells@redhat.com" , "dledford@redhat.com" , "viro@zeniv.linux.org.uk" , "kosaki.motohiro@jp.fujitsu.com" , "linux-api@vger.kernel.org" , "serue@us.ibm.com" , "tglx@linutronix.de" , "paulmck@linux.vnet.ibm.com" , "devel@openvz.org" , "mtk.manpages@gmail.com" Subject: Re: [PATCH v8 2/5] ipc: add sysctl to specify desired next object id References: <20121024151555.5642.79086.stgit@localhost.localdomain> <20121024153509.5642.76385.stgit@localhost.localdomain> <20121024144123.0a77584b.akpm@linux-foundation.org> In-Reply-To: <20121024144123.0a77584b.akpm@linux-foundation.org> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 25.10.2012 01:41, Andrew Morton пишет: > On Wed, 24 Oct 2012 19:35:09 +0400 > Stanislav Kinsbursky wrote: > >> This patch adds 3 new variables and sysctls to tune them (by one "next_id" >> variable for messages, semaphores and shared memory respectively). >> This variable can be used to set desired id for next allocated IPC object. >> By default it's equal to -1 and old behaviour is preserved. >> If this variable is non-negative, then desired idr will be extracted from it >> and used as a start value to search for free IDR slot. >> >> Notes: >> 1) this patch doesn't garantee, that new object will have desired id. So it's >> up to user space how to handle new object with wrong id. >> 2) After sucessfull id allocation attempt, "next_id" will be set back to -1 >> (if it was non-negative). >> >> --- a/ipc/ipc_sysctl.c >> +++ b/ipc/ipc_sysctl.c >> @@ -158,6 +158,7 @@ static int proc_ipcauto_dointvec_minmax(ctl_table *table, int write, >> >> static int zero; >> static int one = 1; >> +static int int_max = INT_MAX; >> >> static struct ctl_table ipc_kern_table[] = { >> { >> @@ -227,6 +228,33 @@ static struct ctl_table ipc_kern_table[] = { >> .extra1 = &zero, >> .extra2 = &one, >> }, >> + { >> + .procname = "sem_next_id", >> + .data = &init_ipc_ns.ids[IPC_SEM_IDS].next_id, >> + .maxlen = sizeof(init_ipc_ns.ids[IPC_SEM_IDS].next_id), >> + .mode = 0644, >> + .proc_handler = proc_ipc_dointvec_minmax, >> + .extra1 = &zero, >> + .extra2 = &int_max, >> + }, >> + { >> + .procname = "msg_next_id", >> + .data = &init_ipc_ns.ids[IPC_MSG_IDS].next_id, >> + .maxlen = sizeof(init_ipc_ns.ids[IPC_MSG_IDS].next_id), >> + .mode = 0644, >> + .proc_handler = proc_ipc_dointvec_minmax, >> + .extra1 = &zero, >> + .extra2 = &int_max, >> + }, >> + { >> + .procname = "shm_next_id", >> + .data = &init_ipc_ns.ids[IPC_SHM_IDS].next_id, >> + .maxlen = sizeof(init_ipc_ns.ids[IPC_SHM_IDS].next_id), >> + .mode = 0644, >> + .proc_handler = proc_ipc_dointvec_minmax, >> + .extra1 = &zero, >> + .extra2 = &int_max, >> + }, >> {} >> }; > > ipc_kern_table[] is (badly) documented in > Documentation/sysctl/kernel.txt. Can we at least mention these > controls in there? Better, create a new way of properly documenting > each control and document these three in that manner? Better still, > document all the other ones as well ;) > Yes, sure. I'll do my best. > The patch adds these controls to CONFIG_CHECKPOINT_RESTORE=n kernels. > Why is this? > I'll fix this. -- Best regards, Stanislav Kinsbursky