On 04/29/2014 04:05 AM, Weng Meiling wrote: > On 2014/4/29 3:05, Dhaval Giani wrote: >> Hi Weng, >> >> I apologize for our tardiness is responding back! >> >> On Sun, Apr 27, 2014 at 9:09 PM, Weng Meiling >> <wengmeiling.w...@huawei.com> wrote: >>> Hi Ivana, >>> What do you think about this problem? >>> >>> Weng Meiling >>> Thanks! >>> >>> On 2014/4/22 11:06, Weng Meiling wrote: >>>> ping... >>>> On 2014/4/10 16:09, Weng Meiling wrote: >>>>> Cgred just migrate forked process when the parent's cgroup is changed, >>>>> so that the forked process can stay in the same cgroup which match the >>>>> cgred rules with it's parent. But there is a situation when parent process >>>>> fork a child process, and exited before it moved into the cgroup matched >>>>> the rules successfullly. The forked child process is also failed into the >>>>> cgroup. This result is inconsistent with rules. So this patch fix the >>>>> problem. Just apply rule for forked process when parent process exited >>>>> when forking. >>>>> >> >> I am not sure of the exact race here. >> >> Parent Forks & Exits >> Child is not classified? >> >> Can you clarify the exact race? >> > The exact race should be parent exit & move to group. > The race may cause child is not classified as rules. > > I can used a example to clarify it: > > start cgred service and the rule: > > root:testd memory test1 > > We have a testd service, and after it starts, it will fork a child process > and exited immediately. The right result should be the testd process (the > parent > and the child) is in memory:test1 according to the rule. But the real result > is > sometime it is not. > > The race is as following: > > parent: cgred: > > fork() > exit() > move process ------ the parent process exited before it > has been moved to the group. > > child move based on event PROC_EVENT_FORK, because the parent has exited, so > cgre_was_parent_changed_when_forking() can't get it's parent's info and return > 0, this will result in the rule will not be executed. So the child process > will > stay the same group with it's parent, But the parent was not moved to the > specified > group before exited, so the child is not in the specified group too. From the > user's > point of view, the result doesn't match the rule. > > The patch add check if parents exits, if parent has exited in > cgre_was_parent_changed_when_forking(), > then returns 1 so that the rule will be executed and the child process can be > moved > to the specified group.
It's impossible to check if the parent process exists this way: >>>>> + if (stat(path, &buff_stat) < 0) >>>>> + return 1; Kernel reuses PIDs, so you have no clue if the parent exited and kernel already reused its PID for other process. cgred is racy and IMO always will be. It's result of making decision based on asynchronous events. We have no control when kernel delivers these events to cgred and how much changed in process structure in the meantime. Another simple race: a process executes a binary, which results into cgred's decision to move the process from cgroup A to B. But the executed process runs for unspecified time in cgroup A until cgred finally gets to CPU and moves the process to B. Hence it could arbitrarily open devices, allocate memory and use too much CPU, all this would be denied in cgroup B. People should not use cgred in the first place, it's just ugly hack, which works without any guarantees. The policy of classifications processes into cgroups must be in kernel and synchronous to be bulletproof. Jan ------------------------------------------------------------------------------ "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available. Simple to use. Nothing to install. Get started now for free." http://p.sf.net/sfu/SauceLabs _______________________________________________ Libcg-devel mailing list Libcg-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libcg-devel
