linux-kernel - Re: [PATCH -mm 1/3] sysv ipc: increase msgmnb default value wrt. the number of cpus

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]

Date:	Thu, 26 Jun 2008 09:12:16 -0700
From:	Andrew Morton <akpm@...ux-foundation.org>
To:	Nadia Derbey <Nadia.Derbey@...l.net>
Cc:	Solofo.Ramangalahy@...l.net, linux-kernel@...r.kernel.org,
	matthltc@...ibm.com, cmm@...ibm.com, manfred@...orfullife.com,
	nickpiggin@...oo.com.au
Subject: Re: [PATCH -mm 1/3] sysv ipc: increase msgmnb default value wrt.
 the number of cpus

On Thu, 26 Jun 2008 16:49:02 +0200 Nadia Derbey <Nadia.Derbey@...l.net> wrote:

> >>+. If the value is positioned from user space to a negative value, then
> >>+  the computation is reenabled. E.g.
> >>+
> >>+  # echo -1 > /proc/sys/kernel/msgmnb
> >>+
> >>+See recompute_msgmnb() function in ipc/ directory for details.
> >>+The value of msgmnb is coupled with the value of msgmni.
> >>+
> > 
> > 
> > The magical positive-versus-negative number trick is a bit obscure, and
> > I don't think there's any precedent for it in the kernel ABI (which is
> > what this is).
> > 
> > Is there anything we can do to reduce the unusualness of this
> > interface?  Say, add a new /proc/sys/kernel/automatic-msgmnb which
> > contains the automatic scaling and leave /proc/sys/kernel/msgmnb
> > containing the manual scaling?  Or something like that?
> 
> Well, I don't know if I well understood your proposal: is it 1 value in 
> automatic-msgmnb and another one in msgmnb?
> I don't clearly see how this could work.
> 
> IMHO, we should keep /proc/sys/kernel/msgmnb as a way to externalize the 
> current tunable value (whether it is automatically recomputed or not).
> 
> Also keep the current strategy: as soon as a value is written into that 
> file, give up with the automatic recomputing.
> 
> And use the file you propose as a way to go back and forth between 
> automatic recomputing and manual setting.
> 
> So the process would be the following:
> 1) kernel boots in "automatic recomputing mode"
>     /proc/kernel/sys/msgmni contains whatever value has been computed
>     /proc/kernel/sys/automatic-msgmnb contains "ON"
> 
> 2) echo <val> > /proc/kernel/sys/msgmnb
>     . sets msg_ctlmnb to <val>
>     . de-activates automatic recomputing (i.e. if, say, a cpu disappears
>       it won't be recompiuted anymore)
>     . /proc/kernel/sys/automatic-msgmnb now contains "OFF"
> 
> Echoing "OFF" into /proc/kernel/sys/automatic-msgmnb would have the same 
> effect (except that msg_ctlmnb's value would stay blocked at its current 
> value)
> 
> 3) echo "ON" > /proc/kernel/sys/automatic-msgmnb
>     . recomputes msgmnb's value based on the current available resources
>     . re-activates automatic recomputing for msgmnb.
> 
> Of course, all this should be applied to msgmni too.
> And may be this automatic-xxx file should be located under sysfs?
>    --> create /sys/kernel/automatic directory and have 1 file per 
> tunable to be scalled (who knows, may be we are adding other ones in th 
> future?)
> 
> Now, may be this is what you actually proposed and I completely 
> misunderstod it?
> 

I don't know what I proposed, sorry ;)  I didn't think about it very hard.

But the positive-values-mean-one-thing/negative-values-mean-another-thing
trick is unusual and rather unpleasing.  I was hoping you guys could come up
with a cleaner interface.

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