[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20121024144123.0a77584b.akpm@linux-foundation.org>
Date: Wed, 24 Oct 2012 14:41:23 -0700
From: Andrew Morton <akpm@...ux-foundation.org>
To: Stanislav Kinsbursky <skinsbursky@...allels.com>
Cc: serge.hallyn@...onical.com, ebiederm@...ssion.com,
linux-kernel@...r.kernel.org, xemul@...allels.com,
catalin.marinas@....com, will.deacon@....com, jmorris@...ei.org,
cmetcalf@...era.com, joe.korty@...r.com, dhowells@...hat.com,
dledford@...hat.com, viro@...iv.linux.org.uk,
kosaki.motohiro@...fujitsu.com, linux-api@...r.kernel.org,
serue@...ibm.com, tglx@...utronix.de, paulmck@...ux.vnet.ibm.com,
devel@...nvz.org, mtk.manpages@...il.com
Subject: Re: [PATCH v8 2/5] ipc: add sysctl to specify desired next object
id
On Wed, 24 Oct 2012 19:35:09 +0400
Stanislav Kinsbursky <skinsbursky@...allels.com> 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 ;)
The patch adds these controls to CONFIG_CHECKPOINT_RESTORE=n kernels.
Why is this?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists