| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
| |
Signed-off-by: Lennart Poettering <lennart@poettering.net>
Acked-by: Dhaval Giani <dhaval.giani@gmail.com>
Signed-off-by: Dhaval Giani <dhaval.giani@gmail.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch introduces a new keywork NAMESPACE which allow cgroups
to be created starting from a certain point as mentioned by the
administrator. This is provided via the configuration file.
Newer APIs will use this feature.
Changes from v1:
1. Attempted to fix the indentation
2. Change a variable name
Signed-off-by: Dhaval Giani <dhaval@linux.vnet.ibm.com>
Acked-by: Balbir Singh <balbir@linux.vnet.ibm.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Hi,
I tested "cgconfig" service with a big /etc/cgconfig.conf file, and the
service failed by signal SIGSEGV.
There are two problems. The first is that "cgconfig" service fails with
a big /etc/cgconfig.conf file. The second is that the error handling is
stopped by signal SIGSEGV.
This patch fixes the second problem.
The following is the gdb output of the problem.
You can see the problem happens in yyerror().
# gdb cgconfigparser
(gdb) run -l /etc/cgconfig.conf
Starting program: /usr/local/sbin/cgconfigparser -l /etc/cgconfig.conf
[Thread debugging using libthread_db enabled]
[New Thread 139764254320624 (LWP 15169)]
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 139764254320624 (LWP 15169)]
0x00007f1d66bd1604 in yyerror (s=0x7f1d66bd955a "syntax error") at parse.y:30
30 fprintf(stderr, "error at line number %d at %c:%s", line_no, *yytext,
(gdb) bt
#0 0x00007f1d66bd1604 in yyerror (s=0x7f1d66bd955a "syntax error")
at parse.y:30
#1 0x00007f1d66bd1a9e in yyparse () at parse.c:1689
#2 0x00007f1d66bd79b5 in cgroup_config_load_config (
pathname=<value optimized out>) at config.c:467
#3 0x00000000004008a3 in main (argc=3, argv=0x7fffa20c8358) at cgconfig.c:60
(gdb)
This problem is due to an invalid access to yytext, and this patch fixes it.
(If you need a big /etc/cgconfig.conf file for reproducing the problem,
please let me know it. I will send it to you without the mailing list.)
Thanks
Ken'ichi Ohmichi
Signed-off-by: Ken'ichi Ohmichi <oomichi@mxs.nes.nec.co.jp>
Acked-by: Dhaval Giani <dhaval@linux.vnet.ibm.com>
Signed-off-by: Dhaval Giani <dhaval@linux.vnet.ibm.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Hi,
When I operated "cgconfig" service on valgrind, I found a memory leak
like the following:
# cat /etc/cgconfig.conf
mount {
cpuset = /cgroup/cpuset;
cpu = /cgroup/cpu;
memory = /cgroup/memory;
}
group user000 {
cpuset {
cpuset.cpus = 0;
cpuset.mems = 0;
}
}
group user000/sleep000 {
cpuset {
cpuset.cpus = 0;
cpuset.mems = 0;
}
}
# valgrind --tool=memcheck --leak-check=yes cgconfigparser -l /etc/cgconfig.conf
==13095== Memcheck, a memory error detector.
==13095== Copyright (C) 2002-2006, and GNU GPL'd, by Julian Seward et al.
==13095== Using LibVEX rev 1658, a library for dynamic binary translation.
==13095== Copyright (C) 2004-2006, and GNU GPL'd, by OpenWorks LLP.
==13095== Using valgrind-3.2.1, a dynamic binary instrumentation framework.
==13095== Copyright (C) 2000-2006, and GNU GPL'd, by Julian Seward et al.
==13095== For more details, rerun with: -v
==13095==
==13095==
==13095== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 4 from 1)
==13095== malloc/free: in use at exit: 43,062 bytes in 10 blocks.
==13095== malloc/free: 129 allocs, 119 frees, 85,399 bytes allocated.
==13095== For counts of detected errors, rerun with: -v
==13095== searching for pointers to 10 not-freed blocks.
==13095== checked 6,795,480 bytes.
==13095==
==13095== 28 bytes in 2 blocks are definitely lost in loss record 1 of 5
==13095== at 0x4A0590B: realloc (vg_replace_malloc.c:306)
==13095== by 0x4C0CC24: yyparse (parse.y:117)
==13095== by 0x4C12914: cgroup_config_load_config (config.c:467)
==13095== by 0x4008A2: main (cgconfig.c:60)
==13095==
==13095== LEAK SUMMARY:
==13095== definitely lost: 28 bytes in 2 blocks.
==13095== possibly lost: 0 bytes in 0 blocks.
==13095== still reachable: 43,034 bytes in 8 blocks.
==13095== suppressed: 0 bytes in 0 blocks.
==13095== Reachable blocks (those to which a pointer was found) are not shown.
==13095== To see them, rerun with: --show-reachable=yes
#
This patch fixes the memory leak.
Thanks
Ken'ichi Ohmichi
Signed-off-by: Ken'ichi Ohmichi <oomichi@mxs.nes.nec.co.jp>
Acked-by: Balbir Singh <balbir@linux.vnet.ibm.com>
Signed-off-by: Dhaval Giani <dhaval@linux.vnet.ibm.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Changelog since v2:
o Avoid breaking ABI by changing the ECGCONFIGPARSEFAIL value.
Changelog since v1:
o Change a parser error value of /etc/cgconfig.conf to ECGCONFIGPARSEFAIL.
The cgconfig service succeeds even if there are something wrong
in /etc/cgconfig.conf. For example, it succeeds even if specifying
not-existing user (nouser) as a perm.task.uid like the following:
# cat /etc/cgconfig.conf
mount {
cpuset = /mnt/cgroups/cpuset;
memory = /mnt/cgroups/memory;
}
group root {
perm {
task {
uid = nouser;
gid = root;
}
admin {
uid = root;
gid = root;
}
}
cpuset {
cpuset.cpus = 0;
cpuset.mems = 0;
}
memory {
memory.use_hierarchy = 1;
memory.limit_in_bytes = 1000000000000;
}
}
#
# service cgconfig start
Starting cgconfig service: parsing failed at line number 10
[ OK ]
# echo $?
0
#
That is not a good behavior and the cgconfig service should fail
if there are something wrong in /etc/cgconfig.conf.
This patch fixes the behavior. In the above case, the behavior is
changed like the following by this patch:
# service cgconfig start
Starting cgconfig service: parsing failed at line number 10
Loading configuration file /etc/cgconfig.conf failed
Cgroup parsing failed
Failed to parse /etc/cgconfig.conf [FAILED]
#
Signed-off-by: Ken'ichi Ohmichi <oomichi@mxs.nes.nec.co.jp>
Signed-off-by: Dhaval Giani <dhaval@linux.vnet.ibm.com>
|
|
|
Signed-off-by: Jan Safranek <jsafrane@redhat.com>
|
