In 2.3.36 there is new variable (memory.oom_control)
in memory controller, this variable should be blacklisted now
(cgsnapshot should have some additonal logic for it)
Signed-off-by: Ivana Hutarova Varekova<varekova@redhat.com> Signed-off-by: Jan Safranek <jsafrane@redhat.com> Acked-by: Dhaval Giani <dhaval.giani@gmail.com>
Jan Safranek [Wed, 10 Nov 2010 15:09:55 +0000 (16:09 +0100)]
Before: Error: libcgroup initialization failed, 50001
Now: Error: libcgroup initialization failed, Cgroup is not mounted
Changelog:
- point to /etc/cgrules/conf when loading of the rules failed
Before: Error: libcgroup failed to initialize rulescache, No such file or
directory
Now: Error: libcgroup failed to initialize rulescache from
/etc/cgrules.conf. No such file or directory
Signed-off-by: Jan Safranek <jsafrane@redhat.com> Acked-by: Ivana Hutarova Varekova <varekova@redhat.com>
This patch add options -f and -d to cgcreate, it cause the permission change of the files of the created group
-d, --dperm mode
sets the permission mode of control groups directory. The mode have to be set using octal numbers e.g. -d 775.
-f, --fperm mode
sets the permission mode of control groups files. The mode have to be set using octal numbers e.g. -f 775.
CHANGELOG v1:
* fix jsafrane foodback thanks for it)
EXAMPLE:
#cgcreate -f 775 -d 775 -g devices:with
#cgcreate -g devices:without
# ll /cgroup/devices/ | grep with
drwxrwxr-x. 2 root root 0 Oct 29 06:55 with
drwxr-xr-x. 2 root root 0 Oct 29 06:55 without
# ll /cgroup/devices/with
total 0
-rwxrwxr-x. 1 root root 0 Oct 29 06:55 cgroup.event_control
-rwxrwxr-x. 1 root root 0 Oct 29 06:55 cgroup.procs
-rwxrwxr-x. 1 root root 0 Oct 29 06:55 devices.allow
-rwxrwxr-x. 1 root root 0 Oct 29 06:55 devices.deny
-rwxrwxr-x. 1 root root 0 Oct 29 06:55 devices.list
-rwxrwxr-x. 1 root root 0 Oct 29 06:55 notify_on_release
-rwxrwxr-x. 1 root root 0 Oct 29 06:55 tasks
# ll /cgroup/devices/without/
total 0
--w--w--w-. 1 root root 0 Oct 29 06:55 cgroup.event_control
-r--r--r--. 1 root root 0 Oct 29 06:55 cgroup.procs
--w-------. 1 root root 0 Oct 29 06:55 devices.allow
--w-------. 1 root root 0 Oct 29 06:55 devices.deny
-r--r--r--. 1 root root 0 Oct 29 06:55 devices.list
-rw-r--r--. 1 root root 0 Oct 29 06:55 notify_on_release
-rw-r--r--. 1 root root 0 Oct 29 06:55 tasks
Signed-off-by: Ivana Hutarova Varekova<varekova@redhat.com> Signed-off-by: Jan Safranek <jsafrane@redhat.com>
This patch adds permission change function
int cg_chmod_recursive(struct cgroup *cgroup, mode_t dir_mode,
int dirm_change, mode_t file_mode, int filem_change);
It changes the directory and files permissions to the given values.
If dirm_change is nonzero, then directory permissions will be set to the second parameter
dir_mode.
If filem_change is nonzero, then directory permissions will be set to the second parameter
file_mode.
CHANGELOG v2:
* fix the return value check for cg_chmod_file procedure
CHANGELOG v1:
* improve the patch description and typo in comment
* fix the problems jsafrane reported
Signed-off-by: Ivana Hutarova Varekova<varekova@redhat.com> Signed-off-by: Jan Safranek <jsafrane@redhat.com>
fixes the cgsnapshot problem with pfile permisssions
cgpconfigparser changes the permissions of all files. That's why to test whether the variable file is writable, there have to be used the variable file from the root group.
CHANGELOG:
* add the information why root group is used for finding which variable is writable
Signed-off-by: Ivana Hutarova Varekova<varekova@redhat.com> Signed-off-by: Jan Safranek <jsafrane@redhat.com>
CHANGELOGS:
CHANGELOG v7
* fix the warnings, remove the root path variable at all, free the name
CHANGELOG v6
* remove the default whitelist (now default state is no whitelist is used)
* incorporate jan's feedback
* dynamic allocation of variable names in lists
* fix the path names and reading
CHANGELOG v5
* add the default blacklist and whitelist
* -w, -b: there is options for setting both blacklist and whitelist configuration files
* -t: add the possibility to read the whitelist strictly
CHANGELOG v3
* white/blacklist is cached
* incorporate jsafraneks feedback
CHANGELOG v2
* add whitelist which describe the set of variables which can be dealt by
cgsnapshot without any problem (the values which with which have cgsnapshot
the problems are there with TODO comment and the reason) without -s option
the skipped variables are output with the warning text
* add the possibility to set the whitelist file
* add the possibility to redirect the output
CHANGELOG v1
* more verbose comments
* tune the variable names/description/usage in display_controller_data
function
* remove unnecessary .stat exception
SYNOPSIS:
cgsnapshot [-h] [-s] [-t] [-b file] [-w file] [-f output_file] [controller] [...]
Generate the configuration file from the given controllers of control groups
-b,--blacklist file Set the blacklist configuration file (default /etc/cgsnapshot_blacklist.conf)
-f,--file Redirect the output to output_file
-h,--help Display this help
-s,--silent Ignore all warnings
-t,--strict Don't show the variables which are not on the whitelist
-w,--whitelist file Set the whitelist configuration file (don't used by default)
Jan Safranek [Tue, 5 Oct 2010 07:51:10 +0000 (13:21 +0530)]
If cgconfigparser fails, it tries to delete created groups. But if they are
in the config file in wrong order, it tries to remove a parent group before
its children are destroyed, resulting into error.
The roll back should use recursive delete. And in addition, it should
delete as much as possible, not to stop on first error.
Signed-off-by: Jan Safranek <jsafrane@redhat.com> Reviewed-By: Ivana Hutarova Varekova <varekova@redhat.com> Tested-By: Ivana Hutarova Varekova <varekova@redhat.com> Signed-off-by: Balbir Singh <balbir@linux.vnet.ibm.com>
Add the flag CGROUP_DAEMON_CANCEL_UNCHANGE_PROCESS.
A new flag CGROUP_DAEMON_CANCEL_UNCHANGE_PROCESS cancels the unchanged process.
If specifying this flag as the argument of cgroup_register_unchanged_process,
a cgrulesengd daemon can move the specified process to right cgroup based on
/etc/cgrules.conf.
Add the flag CGROUP_DAEMON_CANCEL_UNCHANGE_PROCESS.
Hi,
A new flag CGROUP_DAEMON_CANCEL_UNCHANGE_PROCESS cancels the unchanged process.
If specifying this flag as the argument of cgroup_register_unchanged_process,
a cgrulesengd daemon can move the specified process to right cgroup based on
/etc/cgrules.conf.
There is a problem in cgroup_init function
Now if the function strtok_r get at first the controller which
precedes some other controllers on the mount-point option list,
then it removes all next controllers from the list and they are omitted.
The test which is done by strtok_r is redundant (there is already
hasmntopt test), so the patch is removing it at all.
E.G. use commands:
$ mount -t cgroup -o cpu,memory,net_cls lab1 /cgroup/lab1
$ mount -t cgroup -o remount,cpuset,cpu,memory,net_cls lab1 /cgroup/lab1
$ lssubsys -ma
Signed-off-by: Ivana Hutarova Varekova <varekova@redhat.com> Signed-off-by: Balbir Singh <balbir@linux.vnet.ibm.com>
changelog
incorporate Jan's feedback
- test the return value of cgroup_read_value_next
- output \t character only after the whole row of the output
This patch rework cgget to use cgroup_read_vars_{begin/next/end}
iterators - it fix the problem with long variables (like e.g. devices.list)
it also fixes the bug in stat file reading (it shows the variables in root
directory all time)
Signed-off-by: Ivana Hutarova Varekova <varekova@redhat.com> Signed-off-by: Jan Safranek <jsafrane@redhat.com>
This patch adds three iterators api function
cgroup_read_vars_begin
cgroup_read_vars_next
cgroup_read_vars_end
They read the values of the given variable for the specified
controller and control group. The string with the maximal
length max is returned line is returned per
cgroup_read_stats_begin() and cgroup_read_stats_next() call.
(there already are _stat_ versions of function which can read only stat
variables)
Signed-off-by: Ivana Hutarova Varekova <varekova@redhat.com> Signed-off-by: Jan Safranek <jsafrane@redhat.com>
Jan Safranek [Tue, 7 Sep 2010 18:04:52 +0000 (23:34 +0530)]
Rewrite cg_mkdir_p so it does not change current working directory.
Old sequence of operations when creating e.g. /cgroup/cpu
$OLDCWD=$PWD
cd /
mkdir cgroup
cd cgroup
mkdir cpu
cd $OLDCWD
New sequence is:
mkdir /cgroup
mkdir /cgroup/cpu
Some tools, namely those used in /etc/init.d/cgconfig, might be executed with
security constrained context, which does not allow them to access certain
directories (like /var/log/audit). And when e.g. cgconfigparser is executed in
/var/log/audit as current working directory, chdir("/var/log/audit") in
cg_mkdir_p() fails. As consequence, "/etc/init.d/cgconfig start" randomly fails
or succeeds, depending on current working directory and current SELinux policy.
Signed-off-by: Jan Safranek <jsafrane@redhat.com> Signed-off-by: Balbir Singh <balbir@linux.vnet.ibm.com>
Jan Safranek [Tue, 7 Sep 2010 15:02:56 +0000 (20:32 +0530)]
It might be useful to allow empty values in cgconfig.conf, like:
devices {
devices.deny = "";
}
I know, it sounds weird, but Ivana is preparing cgsnapshot tool, which
saves current cgroups into a cgconfig.conf file, and empty values might
occur there.
Signed-off-by: Jan Safranek <jsafrane@redhat.com> Signed-off-by: Balbir Singh <balbir@linux.vnet.ibm.com>
Change the return value to more informative one
the previous error message:
# /sbin/cgconfigparser -l /tmp/cgconfig.conf
can't create group "CBSFxx/Zcz6": Loading configuration file /etc/cgconfig.conf failed
Cgroup values are not equal
the new error message
#/sbin/cgconfigparser -l /etc/cgconfig.conf
can't create group "CBSFxx/Zcz6": Loading configuration file /etc/cgconfig.conf failed
Value setting does not succeed
Signed-off-by: Ivana Hutarova Varekova <varekova@redhat.com> Signed-off-by: Jan Safranek <jsafrane@redhat.com>
-i, --hierrachies
Display attached hierarchy number, if the subsystem is in a hierrachy.
If the option -m is used too, then the hierarchy number is shown only for not mounted hierarchies.
Jan Safranek [Tue, 10 Aug 2010 09:38:14 +0000 (15:08 +0530)]
Some parameters (like devices.allow) shall include a space in their values.
This patch adds possibility to specify parameters names in double quotes,
like:
devices {
devices.allow="c 1:3 mr";
}
The double quotes are not mandatory, old behavior is still there.
As side effect, also parameter names, group names, user names, controller names
etc. can be (optionally) in double quotes and can contain weird characters
- it's a feature, not a bug :). Of course, I could change the grammar to allow
double quotes only in param. values, that shouldn't be a problem.
There is also no advance handling of escape sequences - \", \n, \t does not work
here. That means that parameter values cannot contain newline or double quote
characters - are they required by any controllers?
Signed-off-by: Jan Safranek <jsafrane@redhat.com> Signed-off-by: Balbir Singh <balbir@linux.vnet.ibm.com>
Jan Safranek [Tue, 10 Aug 2010 09:38:14 +0000 (15:08 +0530)]
Current implementation of cgconfig.conf parser stores parameter values in
ugly string (name-value pairs separated by ':', name and value themselves
separated by ' '), which does not allow users to have ' ' and ':' in
parameter values. Both are desired for devices.allow and devices.deny.
Let's rewrite the parser to store the parsed name-value pairs in a
dictionary, without any limitation on characters allowed in names and
values.
Signed-off-by: Jan Safranek <jsafrane@redhat.com> Signed-off-by: Balbir Singh <balbir@linux.vnet.ibm.com>
Jan Safranek [Tue, 10 Aug 2010 09:36:18 +0000 (15:06 +0530)]
Changelog:
- update comments:
- emphasize that 'dictionary' is not hash
- emphasize that order is important
- better describe what CG_DICT_DONT_FREE_ITEMS frees
For subsequent patch (update cgconfig parser to accept quoted-strings as
parameter values), I need a simple storage of name-value pairs, so let's
create simple linked-list framework. It's internal only, these functions
should probably never get public,
It is indeed very simple, it can only add items to the end and iterate
through the items, while preserving their order. It does *not* provide
random access to its items and it is *not* based on hash structure (at least for
now).
Signed-off-by: Jan Safranek <jsafrane@redhat.com> Signed-off-by: Balbir Singh <balbir@linux.vnet.ibm.com>
Changes from previous version:
* put the return value check to separate subpackages
* change the test (info.hierarchy == hierarchy) to
(info.hierarchy != hierarchy) to decrease the nesting depth
* use memset
This patch fixes lssubsys output - it fixes two problems:
1/ if there was subsystem attached to not-mounted hierarchy then
lssubsys -a
does not show this subsystems
EXAMPLE:
FIXED:
$ ./lssubsys -am
cpuset
ns <- controller is in hierarchy but it is not mounted
cpu,devices <- controller is in hierarchy but it is not mounted
cpuacct /cgroup/memoryd
memory /cgroup/memory
freezer
net_cls /cgroup/net_cls
Signed-off-by: Ivana Hutarova Varekova <varekova@redhat.com> Signed-off-by: Balbir Singh <balbir@linux.vnet.ibm.com> Acked-By: Jan Safranek <jsafrane@redhat.com>
Changes from previous version:
* put the return value check to separate subpackages
* change the test (info.hierarchy == hierarchy) to
(info.hierarchy != hierarchy) to decrease the nesting depth
* use memset
This patch fixes lssubsys output - it fixes two problems:
1/ if there was subsystem attached to not-mounted hierarchy then
lssubsys -a
does not show this subsystems
EXAMPLE:
FIXED:
$ ./lssubsys -am
cpuset
ns <- controller is in hierarchy but it is not mounted
cpu,devices <- controller is in hierarchy but it is not mounted
cpuacct /cgroup/memoryd
memory /cgroup/memory
freezer
net_cls /cgroup/net_cls
Signed-off-by: Ivana Hutarova Varekova <varekova@redhat.com> Signed-off-by: Jan Safranek <jsafrane@redhat.com>
Jan Safranek [Mon, 2 Aug 2010 14:30:45 +0000 (16:30 +0200)]
Fix initscript exit codes.
Fix initscript exit codes
- propagate errors from functions to final exit status
- use exit status '1' for generic errors
- return status '2' when the service is called with unknown arguments
Signed-off-by: Jan Safranek <jsafrane@redhat.com> Signed-off-by: Balbir Singh <balbir@linux.vnet.ibm.com>
Eric Brower [Tue, 27 Jul 2010 05:49:37 +0000 (22:49 -0700)]
Update documentation with the new return values
Header file documentation changes; cgroup_create_cgroup() and
cgroup_create_cgroup_from_parent() return ECGROUPNOTEQUAL when create
is successful, but not all controller parameters are successfully
copied.
Signed-off-by: Eric Brower <ebrower@gmail.com> Signed-off-by: Dhaval Giani <dhaval.giani@gmail.com>
Eric Brower [Tue, 27 Jul 2010 05:50:40 +0000 (22:50 -0700)]
split on-disk cgroup validation from parent name generation
Split cgroup_find_parent cgroup/parent on-disk validation from cgroup parent
name generation. This solves a chicken-and-egg problem for callers that need
to obtain a parent name from a cgroup that has not yet been created, such as
cgroup_create_cgroup_from_parent(). The new function enforces the documented
behavior (return NULL) when a "root" cgroup is specified.
Modify cgroup_create_cgroup_from_parent() to use this new function, and clean up
a few possibly-erroneous return values.
Eric Brower [Tue, 27 Jul 2010 05:49:16 +0000 (22:49 -0700)]
Return ECGROUPNOTEQUAL to indicate partial create success
Return ECGROUPNOTEQUAL when copying controller parameters fails--
this allows callers to differentiate between cgroup creation failures and
controller configuration failures, and makes explicit that this function
can return an error code but still have created the cgroup. Callers,
such as cgroup_create_cgroup_from_parent(), can now explicitly ignore
(the unfortunately expected) controller configuration errors.
This patch fixes the return values to meet the standarts.
changed values are:
cgconfig:
* start action: 6: program is not configured
* status action: 3: program is not running
cgred:
* start action: 7: program is not running
* start action: 6: program is not configured
* status action: 3: program is not running
* status action: 2: program is dead and /var/run pid file exists
* stop action: 0: if the service is not running
Signed-off-by: Ivana Hutarova Varekova <varekova@redhat.com> Signed-off-by: Dhaval Giani <dhaval.giani@gmail.com>
Jan Safranek [Mon, 7 Jun 2010 09:58:46 +0000 (11:58 +0200)]
Fix overlaping src and dest buffers in sprintf()
libcgroup compiled with various optimization flags produce strange results
when sprintf's destination and source pointers overlap or are the same.
In addition, use strncpy() instead. This is more or less useless, because
cg_build_path() does not check sizes either, but just for my personal feeling
of correct C code...
Signed-off-by: Jan Safranek <jsafrane@redhat.com> Signed-off-by: Dhaval Giani <dhaval.giani@gmail.com>
Dhaval Giani [Fri, 4 Jun 2010 11:30:58 +0000 (13:30 +0200)]
libcgroup: Do not call exit from within the main library
The autogenerated code fromt the lexer was calling exit on a
fatal error. Do not do that. Instead log the message.
While it is still not clear if this is the correct response
for YY_FATAL_ERROR, we need to gracefully handle errors, and
since this is a path which is very rarely hit, this is still
a low risk change and so we will merge it.
Jan Safranek [Mon, 31 May 2010 15:15:22 +0000 (17:15 +0200)]
Add configure option to set destination directory of pam module.
Add configure option to set destination directory of pam module. The module
can be used right after 'make install', no moving of libraries is required.
Signed-off-by: Jan Safranek <jsafrane@redhat.com> Signed-off-by: Dhaval Giani <dhaval.giani@gmail.com>
Jan Safranek [Mon, 31 May 2010 15:15:08 +0000 (17:15 +0200)]
Rework the way how the libraries are installed.
As pointed out by Kay Sievers on IRC, the pkgconfig file should point to
/usr/lib, where libcgroup.so symlink is located, not to /lib, where is the
real library libcgroup.so.1.0.36.
Therefore it's better to install libraries to /usr/lib, which generated
the right libcgroup.pc and then move all necessary libs to /lib.
Signed-off-by: Jan Safranek <jsafrane@redhat.com> Signed-off-by: Dhaval Giani <dhaval.giani@gmail.com>
Dhaval Giani [Mon, 17 May 2010 16:15:59 +0000 (18:15 +0200)]
libcgroup: Introduce cgroup_basename and modify the functions to use it.
basename() is not safe as it modifies the pointers from time to time.
In order to prevent it, write a safe version of basename which uses basename
internally.
As a side effect, it also clears up the following warning,
api.c: In function ‘cgroup_find_matching_rule’:
api.c:2201: warning: passing argument 1 of ‘__xpg_basename’ discards qualifiers from pointer target type
/usr/include/libgen.h:35: note: expected ‘char *’ but argument is of type ‘const char *’
api.c:2201: warning: passing argument 1 of ‘__xpg_basename’ discards qualifiers from pointer target type
/usr/include/libgen.h:35: note: expected ‘char *’ but argument is of type ‘const char *’
api.c:2201: warning: passing argument 1 of ‘__xpg_basename’ discards qualifiers from pointer target type
/usr/include/libgen.h:35: note: expected ‘char *’ but argument is of type ‘const char *’
api.c:2201: warning: passing argument 1 of ‘__xpg_basename’ discards qualifiers from pointer target type
/usr/include/libgen.h:35: note: expected ‘char *’ but argument is of type ‘const char *’
api.c:2201: warning: passing argument 1 of ‘__xpg_basename’ discards qualifiers from pointer target type
/usr/include/libgen.h:35: note: expected ‘char *’ but argument is of type ‘const char *’
api.c:2201: warning: passing argument 1 of ‘__xpg_basename’ discards qualifiers from pointer target type
/usr/include/libgen.h:35: note: expected ‘char *’ but argument is of type ‘const char *’
api.c:2201: warning: passing argument 1 of ‘__xpg_basename’ discards qualifiers from pointer target type
/usr/include/libgen.h:35: note: expected ‘char *’ but argument is of type ‘const char *’
api.c:2201: warning: passing argument 1 of ‘__xpg_basename’ discards qualifiers from pointer target type
/usr/include/libgen.h:35: note: expected ‘char *’ but argument is of type ‘const char *’
api.c:2201: warning: passing argument 1 of ‘__xpg_basename’ discards qualifiers from pointer target type
/usr/include/libgen.h:35: note: expected ‘char *’ but argument is of type ‘const char *’
api.c:2201: warning: passing argument 1 of ‘__xpg_basename’ discards qualifiers from pointer target type
/usr/include/libgen.h:35: note: expected ‘char *’ but argument is of type ‘const char *’
api.c:2201: warning: passing argument 1 of ‘__xpg_basename’ discards qualifiers from pointer target type
/usr/include/libgen.h:35: note: expected ‘char *’ but argument is of type ‘const char *’
api.c:2201: warning: passing argument 1 of ‘__xpg_basename’ discards qualifiers from pointer target type
/usr/include/libgen.h:35: note: expected ‘char *’ but argument is of type ‘const char *’
api.c:2201: warning: passing argument 1 of ‘__xpg_basename’ discards qualifiers from pointer target type
/usr/include/libgen.h:35: note: expected ‘char *’ but argument is of type ‘const char *’
api.c:2201: warning: passing argument 1 of ‘__xpg_basename’ discards qualifiers from pointer target type
/usr/include/libgen.h:35: note: expected ‘char *’ but argument is of type ‘const char *’
api.c:2201: warning: passing argument 1 of ‘__xpg_basename’ discards qualifiers from pointer target type
/usr/include/libgen.h:35: note: expected ‘char *’ but argument is of type ‘const char *’
api.c:2201: warning: passing argument 1 of ‘__xpg_basename’ discards qualifiers from pointer target type
/usr/include/libgen.h:35: note: expected ‘char *’ but argument is of type ‘const char *’
api.c:2201: warning: passing argument 1 of ‘__xpg_basename’ discards qualifiers from pointer target type
/usr/include/libgen.h:35: note: expected ‘char *’ but argument is of type ‘const char *’
api.c:2201: warning: passing argument 1 of ‘__xpg_basename’ discards qualifiers from pointer target type
/usr/include/libgen.h:35: note: expected ‘char *’ but argument is of type ‘const char *’
api.c:2201: warning: passing argument 1 of ‘__xpg_basename’ discards qualifiers from pointer target type
/usr/include/libgen.h:35: note: expected ‘char *’ but argument is of type ‘const char *’
api.c:2201: warning: passing argument 1 of ‘__xpg_basename’ discards qualifiers from pointer target type
/usr/include/libgen.h:35: note: expected ‘char *’ but argument is of type ‘const char *’
Dhaval Giani [Mon, 17 May 2010 16:15:58 +0000 (18:15 +0200)]
libcgroup: Fix warnings warning about comparisions between signed and unsigned integers
Fix warnings such as
api.c:539: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
api.c:539: warning: signed and unsigned type in conditional expression [-Wsign-compare]
Dhaval Giani [Mon, 17 May 2010 16:15:57 +0000 (18:15 +0200)]
libcgroup: Fix warnings warning of shadowed declaration
Fixes warnings such as
api.c:2764: warning: declaration of ‘stat’ shadows a global declaration [-Wshadow]
/usr/include/sys/stat.h:453: warning: shadowed declaration is here [-Wshadow]
Dhaval Giani [Mon, 17 May 2010 16:15:55 +0000 (18:15 +0200)]
libcgroup: cast CGRULE macros to uid_t
Clears up a few warnings.
api.c:2366: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
api.c:2368: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
api.c:2373: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
api.c:2375: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
Allow cgroup_config_table to be dynamically handled
Allow cgconfigparser to create groups > MAX_GROUPS
From: Balbir Singh <balbir@linux.vnet.ibm.com>
Rafael Tinoco <rafael.tinoco@locaweb.com.br> noticed that the maximum
number of cgroups created using cgconfigparser fell short of 2000. Balbir
found a limitation in the code, that limited this number to a predefined
maximum. This patch fixes the limitation, although not in the most
optimized way, since we want to avoid double parsing of the configuraiton
file.
This patch realloc's the data structure that holds parsed cgroups.
Tested via setting MAX_CGROUPS=1 and loading a configuration file with
2 groups defined. Also tested with a large cgroup file
Test results after loading large_cgconfig.conf (generated using a
script). The size is large, but I wanted to send out the test case
since it adds to our regression bucket.
projects / thirdparty / libcgroup.git / log
