On Tue, Jul 3, 2012 at 1:38 AM, Ivana Varekova <varek...@redhat.com> wrote:
> ----- Original Message -----
>> From: "Dhaval Giani" <dhaval.gi...@gmail.com>
>> To: "Glauber Costa" <glom...@parallels.com>
>> Cc: libcg-devel@lists.sourceforge.net
>> 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
>> <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>
>>
> 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

------------------------------------------------------------------------------
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

Reply via email to