2009/8/26 Krzysztof Taraszka <krzysztof.taraszka@xxxxxxxxxxxxxx> > 2009/8/26 Daniel Lezcano <daniel.lezcano@xxxxxxx> > >> KAMEZAWA Hiroyuki wrote: >> >>> On Mon, 24 Aug 2009 16:11:15 +0200 >>> Daniel Lezcano <daniel.lezcano@xxxxxxx> wrote: >>> >>> >>> >>>> [ snip ] >>>> >>>> >>>>> i think that /proc/meminfo should be mounted after /proc . why? i >>>>>>> think >>>>>>> that, because mounting /proc may override /proc/meminfo >>>>>>> Am I right? :) >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> Ha ! haha ! arrgh ! no way ! You are right :/ >>>>>> >>>>>> >>>>>> >>>>> Hehe ;) >>>>> >>>>> >>>>> >>>>>> In the case of application container, lxc mounts /proc but in the case >>>>>> of >>>>>> system container it is the system who do that so after the >>>>>> /proc/meminfo has >>>>>> been mounted. >>>>>> >>>>>> Maybe we can look at modifying fs/proc/meminfo.c instead. Let me do a >>>>>> small >>>>>> patch for the kernel... >>>>>> >>>>>> >>>>>> >>>>>> >>>>> Okey. I am waiting for your patch :) >>>>> >>>>> >>>> Quick and dirty patch but at least working. It is no synced on the >>>> latest kernel version. >>>> I do not really like to touch fs/proc/meminfo.c but it's an example >>>> here. >>>> >>>> >>>> >>> >>> I'll strongly Nack to this. >>> plz find a way to ln -s /path_to_cgroup/memory.meminfo >>> /mycontainer/meminfo >>> >>> >> >> Yep, I agree with you, I don't like this approach. >> >> We are trying to solve the problem of the userspace tools which look at >> the /proc/meminfo file to display memory informations. That looks weird to >> set a max memory usage of 256MB via the cgroup and having the 'free' command >> showing 4GB of total memory. More than looking weird, Dietmar explained that >> can puzzle applications relying on these informations for taking some >> decisions. >> >> If we consider having /cgroup/mycontainer/memory.meminfo with memory >> information in the same format than /proc/meminfo, that solves partially the >> problem: >> - we run an application container, the application won't mount /proc so >> the lxc tools do that for the application (at least to isolate the pids >> information), it is easy to mount --bind /cgroup/mycontainer/memory.meminfo >> to /proc/meminfo before the application takes the control, that is to say >> before 'exec'. Tested and verified with the memory tools (free, top, etc >> ...) >> >> - we run a system container, we can do this mount-bind but when the >> application, aka /sbin/init, takes the control, the /proc is mounted by the >> system services, so we lose the /proc/meminfo we previously set. Hence >> meminfo in the cgroup directory does not solve the problem for this use >> case. >> >> Any ideas ? >> >> > If I may... I have been thinking about that last few days and... I think > that mounting /proc/meminfo can be done with mounted cgrop and secured by > SMACK64. > I will test it tonight and give you raport how does it works for me. > > Okey. I made few tests and this two ways work: First way: ======= lxc. smack enabled, policy loaded. cgroup not labeled. a) start container b) mount cgroup inside container c) mount --bind /cgroup/foo/memory.meminfo /proc/meminfo d) secure the /cgroup on the host (ie: attr -S -s SMACK64 -V host /cgroup). this step can be done inside lxc tools ;) Second way: ========== lxc. smack enabled, policy loaded. cgroup not labeled. a) do not label whole /cgrop directory (DO NOT DO: attr -S -s SMACK64 -V host /cgroup). Label dedicate files only (for example: /cgroup/cpuset.cpus, /cgroup/vs1/cpuset.cpus, etc). Do not label the /cgrop/vs1 directory. Label with vs1 label only /cgroup/vs1/memory.meminfo. All other files label with host label to do not allow read them. b) start container c) mount cgroup inside container d) mount --bind /cgroup/foo/memory.meminfo /proc/meminfo steps: b, c, d can be done inside lxc tools. step a can't and it is base on the admin policy. I think that the first solution is more automatic and can be done by lxc tools (maybe command line switch? I can prepare a patch for that. -- Krzysztof Taraszka _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/containers
