On Fri, Jun 29, 2012 at 4:18 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()) > > 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. That value will indicate whether or not an error in > the write-to-filesystem routine is considered fatal or not. Non-dirty > values will still be written, but their failures are not considered > fatal. cgroup_modify_cgroup then becomes a simple flusher, and the > problem goes away. >
As I said, I like this solution :-). I will just wait for someone else for finding something that I am missing something and therefore this plan will not work, but if we don't hear anything in a couple of days, we will merge this patch in. > [ v2: Also mark dirty value writes using cgroup_set_value_* ] > [ v3: fail if write fails only for dirty values ] > > Signed-off-by: Glauber Costa <glom...@parallels.com> Acked-by: Dhaval Giani <dhaval.gi...@gmail.com> ------------------------------------------------------------------------------ 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
