----- Original Message ----- > From: "Dhaval Giani" <[email protected]> > To: "Ivana Varekova" <[email protected]> > Cc: [email protected], "Glauber Costa" <[email protected]> > Sent: Tuesday, July 3, 2012 6:21:39 AM > Subject: Re: [Libcg-devel] [PATCH v3] Fix cgroup_modify_cgroup gratuitous > failure > > On Tue, Jul 3, 2012 at 1:38 AM, Ivana Varekova <[email protected]> > wrote: > > ----- Original Message ----- > >> From: "Dhaval Giani" <[email protected]> > >> To: "Glauber Costa" <[email protected]> > >> Cc: [email protected] > >> Sent: Friday, June 29, 2012 12:53:53 PM > >> Subject: Re: [Libcg-devel] [PATCH v3] Fix cgroup_modify_cgroup > >> gratuitous failure > >> > >> On Fri, Jun 29, 2012 at 4:18 PM, Glauber Costa > >> <[email protected]> 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 <[email protected]> > >> > >> Acked-by: Dhaval Giani <[email protected]> > >> > > I don't have any objection regarding the idea behind the patch > > (cgset --copy-from have to be fixed with this change a bit - but > > it was broken before the change too). I will put it to my test set > > and test it a bit. > > Hmm, existing software should just work with this, no? Its all > opaque, > and only those who explicitly set the bit will fail gracefully. > > Dhaval >
The problem already is in the code, it is not created by this patch. Ivana ------------------------------------------------------------------------------ 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 [email protected] https://lists.sourceforge.net/lists/listinfo/libcg-devel
