On 06/22/2012 12:00 PM, Balbir Singh wrote: > On Thu, Jun 21, 2012 at 10:54 PM, Glauber Costa <glom...@parallels.com> wrote: >> On 06/21/2012 07:35 PM, Balbir Singh wrote: >>> >>> On Thu, Jun 21, 2012 at 6:32 PM, Glauber Costa <glom...@parallels.com> >>> wrote: >>>> >>>> On 06/21/2012 04:29 PM, Glauber Costa 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. >>>>> >>>>> Signed-off-by: Glauber Costa <glom...@parallels.com> >>>> >>>> >>>> Ok, sorry: >>>> . >>>> Still one small issue with this patch. I need to make the value dirty >>>> again after the upcoming set_values, or just the first one will work. >>>> >>>> Please you guys let me know if the approach is sensible, then I can send >>>> a new version. >>> >>> >>> Hi, Glauber >>> >>> Based on the file permissions, may be we can do a check upfront.. >>> Today we rely on fwrite failure (I need to go hide somewhere :) ). Is >>> dirty your way of caching the same information instead of reading it >>> again? >>> >>> >> That's very bad, I believe. If the user requested a write in a read-only >> file, that should be properly communicated. >> >> Therefore, using "is the file read-only" to skip trying to write to that >> file is suboptimal at best. >> >> Also, if we read the file from the filesystem, why are we writing it again? >> That's bad because it can undo changes from another process that holds a >> handle to the same cgroup. >> >> So here's what I am proposing, in a nutshell: >> >> * Values read from the filesystem, have dirty = false. >> * Values set by the user, have dirty = true until they are written. >> >> When we modify the cgroup, we only ever attempt to write files that the user >> *explicitly* modified. >> > > That is possible in another round about way, > > 1. do a cgroup_new_cgroup() > 2. Use cgroup_set_value_* for values you want to change > 3. Use cgroup_modify_cgroup() > >> Now, as I said, I rushed a bit to show the problem, and this patch itself is >> missing a piece. I will send you an updated version now > > Thanks, does the above solve the problem you are facing? >
In a quick test, it seemed to work (Well, I have to do add_controller, since I need a valid controller for set_value). Which doesn't mean you don't have a bug. There is nothing reasonable in the current behavior. ------------------------------------------------------------------------------ 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
