On 06/22/2012 07:37 PM, Dhaval Giani wrote: > On Fri, Jun 22, 2012 at 7:58 PM, Glauber Costa <glom...@parallels.com> wrote: >> On 06/22/2012 05:07 PM, Dhaval Giani wrote: >>> >>> Hi, >>> >>> On Thu, Jun 21, 2012 at 5:59 PM, Glauber Costa <glom...@parallels.com> >>> wrote: >>>> >>>> Around one year ago, the following was reported: >>>> http://comments.gmane.org/gmane.comp.lib.libcg.devel/3116 >>>> (Error when calling cgroup_modify_cgroup()) >>>> >>>> Today, I ran into the very same error. Inspecting the code >>>> in libcg, it seemed to me that the best thing to avoid that >>>> is to never attempt to write something the user never wrote to. >>>> >>>> That is because if the user actually tries to write to a read-only >>>> file, we should yield an error, making skipping read-only a bad >>>> solution. >>>> >>>> My solution is to add a field to the value structure indicating >>>> whether or not it is dirty. cgroup_modify_cgroup then becomes a >>>> flusher, and the problem goes away. >>>> >>> >>> OK, good point. But consider the following use case. I want to >>> duplicate a cgroup, except for its name? >>> >>> Or, let's say CPU and cpuset are mounted together, and I want to just >>> modify the cpu parameters, and not cpuset. I duplicate the parent >>> using cgroup_get_cgroup, have a modified name, and modified cpu >>> paramenters, and then write to the child. How else do you suggest >>> doing that, apart from knowing how the cgroups is setup on that >>> system? >>> >>> How does one handle that case? >> >> >> I don't follow totally. >> If I understand the API correctly, you would do get_cgroup() in cgroup A, >> and then use something like copy_cgroup(), right? >> > > Umm. No. copy_cgroup just copies the data structure. Let's talk about > a live system, which has cpusets and cpus mounted together. My > application cares about creating a child cgroup under the cgroup it > has control of, and just cares about cpus. However, there is still > need to set up cpuset.cpus/mems, otherwise that cgroup is useless (as > proceses cannot be moved there). Now, for this, we are happy with > parents values, and just do a get_cgroup for the parents, and modify > the cpu parameters. Now, ever if we don't dirty cpuset, since that has > not been modified, we will need to write out cpuset values, otherwise > the group is useless, short of the application knowing about it. > > Now, I agree this is a design failure, and needs to be fixed in > another fashion (and I have some half written code for that, but there > are too many things occupying me to finish it), but we still have use > cases where cgroups is setup like that, and being used, and we do need > to support it. > > Dhaval > Well, it's your library =)
But just to keep in mind: I'll give you yet another example of where your file permission logic will fail: writes to memory.use_hierarchy are permitted. But they will fail if its value is already 1. So if you are copying a cgroup that has that flag set to 1, and trying to write it back, you will fail. Of course the situation here is the same as with cpuset: I don't consider it good kernel behavior. But it is there for a while now, and if you want the library to work with such kernels, a way to do it is needed. ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Libcg-devel mailing list Libcg-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libcg-devel
