[lxc-devel] Memory Resources

Daniel Lezcano daniel.lezcano at free.fr
Mon Aug 24 03:11:54 PDT 2009


Krzysztof Taraszka wrote:
> 2009/8/24 Daniel Lezcano <daniel.lezcano at free.fr>
>
>   
>> Krzysztof Taraszka wrote:
>>
>>     
>>> 2009/8/24 Daniel Lezcano <dlezcano at fr.ibm.com>
>>>
>>>
>>>
>>>       
>>>> Krzysztof Taraszka wrote:
>>>>
>>>>
>>>>
>>>>         
>>>>> 2009/8/24 Daniel Lezcano <daniel.lezcano at free.fr>
>>>>>
>>>>>  Krzysztof Taraszka wrote:
>>>>>
>>>>>
>>>>>           
>>>>>>  2009/8/23 Daniel Lezcano <daniel.lezcano at free.fr>
>>>>>>
>>>>>>
>>>>>>             
>>>>>>> (...)
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>  With the lxc tools I did:
>>>>>>>
>>>>>>>
>>>>>>>               
>>>>>>>>     lxc-execute -n foo /bin/bash
>>>>>>>>     echo 268435456 > /cgroup/foo/memory.limit_in_bytes
>>>>>>>>     mount --bind /cgroup/foo/memory.meminfo /proc/meminfo
>>>>>>>>     for i in $(seq 1 100); do sleep 3600 & done
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>                 
>>>>>>> (...)
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>  :)
>>>>>>>
>>>>>>>
>>>>>>>               
>>>>>>>>  hmmm... I think that access to the cgroup inside container is very
>>>>>>>>
>>>>>>>>
>>>>>>>>                 
>>>>>>> risk
>>>>>>> because I am able to manage for example memory resources (what if I am
>>>>>>> not
>>>>>>> the host owner and... I can give me via non-secure mounted /cgroup
>>>>>>> (inside
>>>>>>> container) all available memory resources...).
>>>>>>> I think that the /proc/meminfo should be pass to the container in the
>>>>>>> other
>>>>>>> way, but this is the topic for the other thread.
>>>>>>>
>>>>>>>
>>>>>>>  It is not a problem, I did it in this way because it's easy to test
>>>>>>> but
>>>>>>>
>>>>>>>
>>>>>>>               
>>>>>> in
>>>>>> a real use case, the memory limit is setup by the lxc configuration
>>>>>> file
>>>>>> and
>>>>>> the cgroup directory will be no longer accessible from the container.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>             
>>>>> So.. how there will be another method (more secure) for giving
>>>>> /proc/meminfo
>>>>> with limits to the container, right?
>>>>>
>>>>>
>>>>>
>>>>>           
>>>> Same method. The lxc tools can be configured with a fstab to mount more
>>>> mount points, furthermore if memory.meminfo is available I will add the
>>>> code
>>>> to mount it automatically to /proc/meminfo in the lxc tools.
>>>>
>>>>
>>>>
>>>>         
>>> Hmm... setup_fs() from lxc_init.c or another way?
>>>
>>>
>>>       
>> No, I was thinking in the setup_cgroup() function in conf.c.
>>
>> Something like:
>>
>> ...
>>
>> if (!access("/var/lib/lxc/mycontainer/nsgroup/memory.meminfo"), F_OK) {
>>   mount("/var/lib/lxc/mycontainer/nsgroup/memory.meminfo", "/proc/meminfo",
>> MS_BIND, ...);
>> }
>>
>> ...
>>
>>
>> but a bit more clean :)
>>
>>     
>
>
> hmm... ok, got it, but don't know why does it won't work ;)
>
> @@ -999,12 +999,14 @@
>  static int setup_cgroup(const char *name)
>  {
>      char filename[MAXPATHLEN];
> +    char meminfofilename[MAXPATHLEN];
>      char line[MAXPATHLEN];
>      struct stat s;
>      int ret;
>
>      snprintf(filename, MAXPATHLEN, LXCPATH "/%s/cgroup", name);
> -
> +    snprintf(meminfofilename, MAXPATHLEN, LXCPATH
> "/%s/nsgroup/memory.meminfo", name);
> +
>      if (stat(filename, &s)) {
>          SYSERROR("failed to stat '%s'", filename);
>          return -1;
> @@ -1024,6 +1026,10 @@
>
>      INFO("cgroup has been setup");
>
> +    /* mount memory.meminfo as /proc/meminfo */
> +    if (!access(meminfofilename, F_OK)) {
> +        mount(meminfofilename, "/proc/meminfo", "none", MS_BIND, 0);
> +     }
>      return 0;
>  }
>
>
> hmm... any idea Daniel? :)
>   
Yep, can you check the return code of the mount call and return an error ?
if (mount(....)) {
    SYSERROR("failed to mount '%s' to '/proc/meminfo'", meminfofilename);
    return -1;
}
at least to verify if this does not fail.
and maybe add an INFO trace if the mount is successful saying 
"/proc/meminfo" is setup with the cgroup.

ps : you should launch the command with the "-l INFO" to see the message.


More information about the Containers mailing list