Re: [PATCH] Relax ns_can_attach checks to allow attaching to grandchild cgroups

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On pią, gru 19, 2008 at 04:23:04 -0600, Serge E. Hallyn wrote:> Quoting Andrew Morton (akpm@xxxxxxxxxxxxxxxxxxxx):> > (cc containers@xxxxxxxxxxxxxx)> > > > Please don't send patches via private email!
My apologies.
> I trust (since you're not removing it) that the restriction that> the target cgroup be empty is not a problem?
Sigh, good catch. I'm building my lxc-based environment slowly and I'monly testing the most basic stuff currently, so I'd bug you about iteventually.
Frankly, I don't understand the reason behind these restrictions andfeel like I'm missing some important piece of a puzzle. In my tests allthe tasks in question are living in the same namespace (though it won'talways be so), so I'd guess I should be able to move the tasks freelybetween cgroups. Why exactly does the target cgroup have to be empty?
Also, should we remember the task->nsproxy pointer in the cgroup dataand ignore hierarchy if it matches? I guess it would be safe to storethe raw pointer without refcounting it in any way as we'd neverdereference it (could keep it as uintptr_t to reinforce the idea) butonly compare with another pointer.
Does that make any sense? Or should I simply mount the cgroup fs withoutthe ns subsystem and forget the whole thing? What exactly do I lose bydoing so?
> Also, 'rule 1' in the comment above ns_can_attach should be modified> accordingly (s/child/descendant).
Indeed. Will resend after receiving some enlightenment about the above.
Thank you for your comments.
Best regards, Grzegorz Nosek_______________________________________________Containers mailing listContainers@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx://lists.linux-foundation.org/mailman/listinfo/containers


[Index of Archives]     [Cgroups]     [Netdev]     [Linux Wireless]     [Kernel Newbies]     [Security]     [Linux for Hams]     [Netfilter]     [Bugtraq]     [Yosemite Forum]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux Admin]     [Samba]

  Powered by Linux