Hide Forgot
1. Feature Overview: Feature Id: [76945] a. Name of Feature: libcgroup support for large pages b. Feature Description Support for large pages in libcgroup 2. Feature Details: Sponsor: LTC Kernel Architectures: ppc64, x86_64, Arch Specificity: purely common code Affects Kernel Modules: No Delivery Mechanism: Direct from Community Category: other Request Type: Package - Feature from Upstream d. Upstream Acceptance: Accepted Sponsor Priority P2 f. Severity: high IBM Confidential: No Code Contribution: IBM code g. Component Version Target: --- 3. Business Case HPC customers use cgroups for controlling resource consumption by users. Many HPC users use large pages, so need to be able to track/control large page usage in the same manner as other memory usage. 4. Primary contact at Red Hat: John Jarvis, jjarvis 5. Primary contacts at Partner: Project Management Contact: Michael L. Hohnbaum, hbaum.com Technical contact(s): CIJU R. KOLLANOOR, cijurajan.com
(In reply to comment #0) > Request Type: Package - Feature from Upstream > d. Upstream Acceptance: Accepted Could you please specify, which patches are requested? I do not recall any specific functionality for large pages in libcgroups added recently. Or do you request new controllers/parameters/functionality directly in Linux kernel? Please use 'kernel' component if so, libcgroup package is just user-space library and collection of simple tools to help applications manage cgroups.
------- Comment From hohnbaum.com 2011-12-05 19:24 EDT------- Sorry, we got our messages crossed internally at IBM on this item. We need the 0.37-3 version of libcgroup to pick up a critical bug fix for our LoadLeveler product, or if not a version upgrade, then a patch from that version incorporated into the version shipping with RHEL 6.x. We are also working on large page support for cgroups, but that is indeed a kernel change and has not yet been submitted upstream. We will be requesting that support in the RHEL 7.0 release. Ciju will provide details on the bug fix along with the patch. We will update the bugzilla summary line to reflect the specific fix we are looking for.
------- Comment From cijurajan.com 2011-12-20 00:00 EDT------- Hello Redhat, There was one bug related to assign/admin id in libcgroup. This is fixed is in the mainline version. This bug fix is needed for one of our product to work properly. Here is the patch that fixes this problem: http://libcg.git.sourceforge.net/git/gitweb.cgi?p=libcg/libcgroup-context.git;a=commit;h=17a40d649c9dfc539b18784c644d8a45916ecd68 Description: admin_id and admin_gid are not displayed correctly. This is because cgroup_fill_cgc() does not differentiate between the cgroup control files and tasks file. So cgroup->control_uid and cgroup->control_gid fields are getting populated with the uid and gid of tasks file. This patch fixes this problem by adding a check in the cgroup_fill_cgc() function to see if the file is a 'tasks' file or not. Please pick this patch into libcgroup version that will be included in RHEL6.3. Or take the latest mainline version of libcgroup, in which this problem is fixed. -Ciju
IBM is signed up to test and provide feedback, setting OtherQA.
------- Comment From cijurajan.com 2011-12-22 08:14 EDT------- Redhat, Attaching the patch also. Please include it in RHEL6.3. -Ciju
Created attachment 549191 [details] Patch to fix the admin/assign id bug ------- Comment (attachment only) From cijurajan.com 2011-12-22 08:15 EDT-------
This request was evaluated by Red Hat Product Management for inclusion in the current release of Red Hat Enterprise Linux. Because the affected component is not scheduled to be updated in the current release, Red Hat is unfortunately unable to address this request at this time. It has been proposed for the next release. If you would like it considered as an exception in the current release, please ask your support representative.
------- Comment From tpnoonan.com 2012-02-13 13:12 EDT------- hi red hat, can you reconsider for rhel6.3 based on the following? many thanks > The problem being addressed by this request affects the HPC related product - > LoadLeveler. Please escalate this rejection with Red Hat. Thanks. > Problem: > When we invoke cgroup_get_cgroup() in libcgroup library to get the cgroup meta > data, the admin_id and admin_gid are not displayed correctly. This is because > cgroup_fill_cgc() does not differentiate between the cgroup control files and > tasks file. So cgroup->control_uid and cgroup->control_gid fields are getting > populated with the uid and gid of tasks file > Business impact: > Load Leveler software has the functionality to give privileges to certain users > to administer the cgroup and also the power to assign tasks to the groups based > on the configuration suggested by the administrator. This feature will not work > because of this bug in libcgroup package. According to Load Leveler team, this > is a critical feature.
------- Comment From markwiz.com 2012-04-25 20:38 EDT------- Red Hat- John Jarvis at Red Hat has ask us to test this. Which build will the fix be in for us to test?
(In reply to comment #18) > Red Hat- John Jarvis at Red Hat has ask us to test this. Which build will the > fix be in for us to test? libcgroup-0.37-4 in 6.3 Beta
IBM, have you been able to test and verify this?
------- Comment From hbaum.com 2012-05-22 15:37 EDT------- Verified by IBM. Tester will provide more details.
------- Comment From raghavendra.kt.com 2012-05-23 06:11 EDT------- (In reply to comment #25) > Verified by IBM. Tester will provide more details. Here are the brief l steps with the test program assign_admin_test.c #include <libcgroup.h> /* * Compilation: * gcc -g assign_admin_test.c -lcgroup -I /usr/include/ -I /usr/include/libcgroup/ * test performed: * step 1) * create a new user and have his permission for tasks file by updating in cgconfig.conf * similar like this. * * group newuser { perm { admin { uid = root; gid = root; } task { uid = newuser; gid = newuser; } } memory { memory.limit_in_bytes = 512M; } step 2) Have this entry in cgrules.conf newuser * /newuser step 3) restart cgconfig check for /cgroup/<controlgroup>/newuser step 4) create a test directory under /cgroup/<controlgroup>/newuser controlgroup for e.g here is memory step 5) execute the test binary, you should not see control_uid/gidoverwritten with task uid/gid in the example task uid/gid is newuser and control uid/gid is root */ int main () { int ret; struct cgroup *cgroup; ret = cgroup_init(); if (ret) { printf(" error cgroup init\n"); goto error; } cgroup = cgroup_new_cgroup("newuser/test"); ret = cgroup_get_cgroup(cgroup); if (ret) { printf(" error getcgroup \n"); goto error; } ret = cgroup_attach_task_pid(cgroup, getpid()); if (ret) { printf(" error attach task \n"); goto error; } getchar(); cgroup_free(&cgroup); return 0; error: return 1; }
(In reply to comment #22) > ------- Comment From raghavendra.kt.com 2012-05-23 06:11 EDT------- > (In reply to comment #25) > > Verified by IBM. Tester will provide more details. > > Here are the brief l steps with the test program > > assign_admin_test.c > #include <libcgroup.h> > /* > * Compilation: > * gcc -g assign_admin_test.c -lcgroup -I /usr/include/ -I > /usr/include/libcgroup/ > * test performed: > * step 1) > * create a new user and have his permission for tasks file by updating in > cgconfig.conf > * similar like this. > * > * > group newuser { > perm { > admin { > uid = root; > gid = root; > } > task { > uid = newuser; > gid = newuser; > } > } > memory { > memory.limit_in_bytes = 512M; > } An extra closing bracket is needed here. 'newuser' user/group need to be created too. > step 2) Have this entry in cgrules.conf > newuser * /newuser > step 3) restart cgconfig check for /cgroup/<controlgroup>/newuser > step 4) create a test directory under /cgroup/<controlgroup>/newuser > controlgroup for e.g here is memory > step 5) execute the test binary, you should not see > control_uid/gidoverwritten with task uid/gid > in the example task uid/gid is newuser and control uid/gid is root I can get the program to run as root with the above steps but I do not understand how to verify the control uid/gid is not overwritten with task uid/gid How do you check the control uid/gid?
------- Comment From raghavendra.kt.com 2012-05-25 12:30 EDT------- (In reply to comment #29) > (In reply to comment #22) > > (In reply to comment #25) > > > Verified by IBM. Tester will provide more details. > > > > Here are the brief l steps with the test program > > > > assign_admin_test.c > > #include <libcgroup.h> > > /* > > * Compilation: > > * gcc -g assign_admin_test.c -lcgroup -I /usr/include/ -I > > /usr/include/libcgroup/ > > * test performed: > > * step 1) > > * create a new user and have his permission for tasks file by updating in > > cgconfig.conf > > * similar like this. > > * > > * > > group newuser { > > perm { > > admin { > > uid = root; > > gid = root; > > } > > task { > > uid = newuser; > > gid = newuser; > > } > > } > > memory { > > memory.limit_in_bytes = 512M; > > } > An extra closing bracket is needed here. 'newuser' user/group need to be > created too. > > step 2) Have this entry in cgrules.conf > > newuser * /newuser > > step 3) restart cgconfig check for /cgroup/<controlgroup>/newuser > > step 4) create a test directory under /cgroup/<controlgroup>/newuser > > controlgroup for e.g here is memory > > step 5) execute the test binary, you should not see > > control_uid/gidoverwritten with task uid/gid > > in the example task uid/gid is newuser and control uid/gid is root > > I can get the program to run as root with the above steps but I do not > understand how to verify the control uid/gid is not overwritten with task > uid/gid > > How do you check the control uid/gid? One method is debugging with gdb and cross checking that control uid/gid has not been overwritten with task uid/gid.
(In reply to comment #24) > One method is debugging with gdb and cross checking that control uid/gid has > not been overwritten > with task uid/gid. Thanks, I was unable to verify this personally but the patch is included in the source rpm and is applied successfully during build of the errata packages for each arch: [jbrier@jb-t520 logs]$ pwd /mnt/curly/redhat/brewroot/packages/libcgroup/0.37/4.el6/data/logs [jbrier@jb-t520 logs]$ for i in `ls`; do grep admin-assign-id.patch $i/build.log; done; Patch #6 (libcgroup-0.37-admin-assign-id.patch): + echo 'Patch #6 (libcgroup-0.37-admin-assign-id.patch):' + /bin/cat /builddir/build/SOURCES/libcgroup-0.37-admin-assign-id.patch Patch #6 (libcgroup-0.37-admin-assign-id.patch): + echo 'Patch #6 (libcgroup-0.37-admin-assign-id.patch):' + /bin/cat /builddir/build/SOURCES/libcgroup-0.37-admin-assign-id.patch Patch #6 (libcgroup-0.37-admin-assign-id.patch): + echo 'Patch #6 (libcgroup-0.37-admin-assign-id.patch):' + /bin/cat /builddir/build/SOURCES/libcgroup-0.37-admin-assign-id.patch Patch #6 (libcgroup-0.37-admin-assign-id.patch): + echo 'Patch #6 (libcgroup-0.37-admin-assign-id.patch):' + /bin/cat /builddir/build/SOURCES/libcgroup-0.37-admin-assign-id.patch Patch #6 (libcgroup-0.37-admin-assign-id.patch): + echo 'Patch #6 (libcgroup-0.37-admin-assign-id.patch):' + /bin/cat /builddir/build/SOURCES/libcgroup-0.37-admin-assign-id.patch + echo 'Patch #6 (libcgroup-0.37-admin-assign-id.patch):' Patch #6 (libcgroup-0.37-admin-assign-id.patch): + /bin/cat /builddir/build/SOURCES/libcgroup-0.37-admin-assign-id.patch IBM has tested/verified this and the IBM Verified is set. Additionally marking SanityOnly
Adding SanityOnly back, IBM please do not remove this.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. http://rhn.redhat.com/errata/RHBA-2012-0867.html