Am 05.11.2014 um 13:41 schrieb Serge E. Hallyn: > Quoting Richard Weinberger (richard@xxxxxx): >> Am 05.11.2014 um 11:41 schrieb Chen Hanxiao: >>> We lack of pid hierarchy information, and this will lead to: >>> a) we don't know pids' relationship, who is whose child: >>> /proc/PID/ns/pid only tell us whether two pids live in different ns >>> b) bring trouble to nested lxc container check/restore/migration >>> c) bring trouble to pid translation between containers; >>> >>> This patch will show the hierarchy of pid namespace >>> by pidns_hierarchy like: >>> >>> [root@localhost ~]#cat /proc/pidns_hierarchy >>> 18060 18102 1534 >>> 18060 18102 1600 >>> 1550 >> >> Hmm, what about printing the pid hierarchy in the same way as /proc/self/mountinfo >> does with mount namespaces? >> Your current approach is not bad but we should really try to be consistent with existing >> sources of information. > > Good point. How would you structure it to make it look mor elike mountinfo? > Adding the pidns inode number (in place of a mount sequence number) might be > useful, but it sounds like you have a more concrete idea? Just list <init_PID> <parent_of_init_PID>. This way we have exactly one information record per line and always exactly two columns to parse. e.g. [root@localhost ~]#cat /proc/pidns_hierarchy 1550 1 18060 1 18102 18060 1534 18102 1600 18102 >> This function allocates memory per PID. If we have lots of PIDs, how does this scale? >> I'd go so far and say this can be a DoS'able issue if the pidns_hierarchy file is opened multiple times... > > It's not per pid, but per init-pid. For non-reaper pids he bails and continue > through the loop a few lines above. This still may be DOS-able if users don't > have kmem restrictions to prevent a ton of pid namespaces, but then the > namespaces themselves will take a lot more memory than the representation here. Ah, I've overlooked that fact. If it is per init-pid it is not that bad. :-) Thanks, //richard _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/containers
