Messages in this thread | | | Date | Mon, 05 May 2014 22:59:50 +0300 | From | Marian Marinov <> | Subject | Re: [PATCH] IPC initialize shmmax and shmall from the current value not the default |
| |
On 05/04/2014 02:17 PM, Manfred Spraul wrote: > Hi Marian, > > Note: The limits will soon be increased to (nearly) ULONG_MAX. > I.e.: If you propose the patch because you are running into issues with a too small SEMMAX after an > unshare(CLONE_NEWIPC), then this will be fixed soon. > > > On 05/04/2014 01:53 AM, Davidlohr Bueso wrote: >> On Sun, 2014-05-04 at 01:48 +0300, Marian Marinov wrote: >>> When we are creating new IPC namespace that should be cloned from the current namespace it is a good idea to copy the >>> values of the current shmmax and shmall to the new namespace. > The idea sounds reasonable: > If an admin has reduced the limits, then the reduction should also apply after a unshare(CLONE_NEWIPC). > > But: > Your patch doesn't use the current shmmax, it uses the shmmax from init_ipc_ns. > Would it be possible to use the current values?
In my tests it worked exactly as expected. Here is an example:
[root@sp2 ~]# sysctl -a|grep shmmax kernel.shmmax = 68719476736 [root@sp2 ~]# lxc-attach -n cent_plain [root@localhost ~]# sysctl -a|grep shmmax kernel.shmmax = 68719476736 [root@localhost ~]# halt [root@sp2 ~]# sysctl -a|grep shmmax kernel.shmmax = 68719476736 [root@sp2 ~]# sysctl kernel.shmmax=34359738368 kernel.shmmax = 34359738368 [root@sp2 ~]# lxc-start -n cent_plain -d [root@sp2 ~]# lxc-attach -n cent_plain [root@localhost ~]# sysctl -a|grep shmmax kernel.shmmax = 34359738368 [root@localhost ~]#
So it seams to work as expected :)
It works because wen you setup a new shmmax limit it is actually the limit in the init_ipc_ns. So when we are creating a new ipc_ns its ok to copy the values from init_ipc_ns.
-Marian
> >> Why is this a good idea? >> >> This would break userspace that relies on the current behavior. >> Furthermore we've recently changed the default value of both these >> limits to be as large as you can get, thus deprecating them. I don't >> like the idea of this being replaced by namespaces. > Davidlohr: We are not deprecating them, we make the default huge. > The limits should stay as usable as they were. > > With regards to breaking user space, I must think about it a bit more. > Right now, each new namespace starts with SEMMAX=32MB, i.e. an often unusable default. > > -- > Manfred >
-- Marian Marinov Founder & CEO of 1H Ltd. Jabber/GTalk: hackman@jabber.org ICQ: 7556201 Mobile: +359 886 660 270
| |