> -----Original Message----- > From: Richard Weinberger [mailto:richard@xxxxxx] > Sent: Wednesday, November 05, 2014 8:52 PM > To: Serge E. Hallyn > Cc: Chen, Hanxiao/陈 晗霄; Eric W. Biederman; Serge Hallyn; Oleg Nesterov; > containers@xxxxxxxxxxxxxxxxxxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx; Mateusz > Guzik; David Howells > Subject: Re: [PATCH 1/2v6] procfs: show hierarchy of pid namespace > > 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 > But this style lacks of *level* information: Ex: 1->18060->18102->1600->1700 If we want to check the 1700's level in pid ns Style 1: 18060 18102 1600 1700 Style 2: 18060 1 18102 18060 1600 18102 1700 1600 If we had a little more containers, Style 2 would not be clear enough. 1 line vs $(PID level) line If there were no more related information to show, I think style 1 looks better. Thanks, - Chen > >> 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
