Krzysztof Taraszka wrote: > 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. > I do not know smack, what does smack here ? Will this solution avoid the container to overwrite /proc/meminfo by remounting /proc ? _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/containers
