linux-kernel - Re: [PATCH v8 2/5] ipc: add sysctl to specify desired next object id

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <5088EFE6.2040900@parallels.com>
Date:	Thu, 25 Oct 2012 11:53:10 +0400
From:	Stanislav Kinsbursky <skinsbursky@...allels.com>
To:	Andrew Morton <akpm@...ux-foundation.org>
CC:	"serge.hallyn@...onical.com" <serge.hallyn@...onical.com>,
	"ebiederm@...ssion.com" <ebiederm@...ssion.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Pavel Emelianov <xemul@...allels.com>,
	"catalin.marinas@....com" <catalin.marinas@....com>,
	"will.deacon@....com" <will.deacon@....com>,
	"jmorris@...ei.org" <jmorris@...ei.org>,
	"cmetcalf@...era.com" <cmetcalf@...era.com>,
	"joe.korty@...r.com" <joe.korty@...r.com>,
	"dhowells@...hat.com" <dhowells@...hat.com>,
	"dledford@...hat.com" <dledford@...hat.com>,
	"viro@...iv.linux.org.uk" <viro@...iv.linux.org.uk>,
	"kosaki.motohiro@...fujitsu.com" <kosaki.motohiro@...fujitsu.com>,
	"linux-api@...r.kernel.org" <linux-api@...r.kernel.org>,
	"serue@...ibm.com" <serue@...ibm.com>,
	"tglx@...utronix.de" <tglx@...utronix.de>,
	"paulmck@...ux.vnet.ibm.com" <paulmck@...ux.vnet.ibm.com>,
	"devel@...nvz.org" <devel@...nvz.org>,
	"mtk.manpages@...il.com" <mtk.manpages@...il.com>
Subject: Re: [PATCH v8 2/5] ipc: add sysctl to specify desired next object
 id

25.10.2012 01:41, Andrew Morton пишет:
> 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 ;)
>

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
--
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/