[Devel] Re: [lxc-devel] Memory Resources

[Serge E. Hallyn]

Quoting Daniel Lezcano (daniel.lezcano at free.fr):
> Serge E. Hallyn wrote:
>> Quoting Daniel Lezcano (daniel.lezcano at free.fr):
>>   
>>> Krzysztof Taraszka wrote:
>>>     
>>>> 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 ?
>>>     
>>
>> Right, in the first way he is labeling the whole cgroupfs with a label
>> which prevents the container from mounting it.  In the second way,
>> the specific files are labeled.
>>   
>
> Ah, got it ! :)
>
> The idea of Kamezawa-san to use a fuse proc is maybe a good idea in this  
> case. So we can address the entire /proc specific informations. For  

I agree, nice idea.  And hopefully pretty simple to whip up for the
meminfo and cpuinfo files as an example.

Are you thinking a fuse fs which takes a config file, holds an open
ref to its ancestor /proc, and for each file looks in a config file to
decide whether to show userspace:
	1. nothing
	2. the underlying file, unprocessed
	3. a simple ascii file instead
	4. the underlying file, processed?

> example, like the /proc/meminfo, there is the /proc/cpuinfo. If you  
> restrict the usage to a subset of your cpus with cpuset and you look at  
> /proc/cpuinfo, you see all the cpus; it is not a big problem until a  
> computation application looks at this file and choose to fork(n cpus)  
> and set the affinity of each process to each cpu ... AFAIR, this is the  
> case for HPC applications.

-serge
_______________________________________________
Containers mailing list
Containers at lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/containers