Quoting Chen, Hanxiao (chenhanxiao@xxxxxxxxxxxxxx): > Hi, > > > -----Original Message----- > > From: Serge E. Hallyn [mailto:serge@xxxxxxxxxx] > > Sent: Monday, September 29, 2014 10:00 PM > > Subject: Re: [PATCHv3 2/2] /proc/PID/status: show all sets of pid according to > > ns > [snip] > > > > > > > > This patch adds four fields: NStgid, NSpid, NSpgid and NSsid: > > > > a) In init_pid_ns, nothing changed; > > > > > > > > b) In one pidns, will tell the pid inside containers: > > > > NStgid: 21776 5 1 > > > > NSpid: 21776 5 1 > > > > NSpgid: 21776 5 1 > > > > NSsid: 21729 1 0 > > > > ** Process id is 21776 in level 0, 5 in level 1, 1 in level 2. > > > > > > > > c) If pidns is nested, it depends on which pidns are you in. > > > > NStgid: 5 1 > > > > NSpid: 5 1 > > > > NSpgid: 5 1 > > > > NSsid: 1 0 > > > > ** Views from level 1 > > > > > > > > > > This patch is simple, useful and safe. > > > But currently there is not any feedbacks. > > > > > > Any comments or ideas? > > > > Thanks, Chen. The code looks fine. My concern is that you are > > exposing information which cannot be checkpointed and restarted. > > In particular, if I'm inside a nested container, so I'm in pidns > > level 3, then my own NSpid info, when I read it, will show the > > pids at parent namespaces. If I'm restarted at the third pidns > > level, only the one pid can be restored. > > If you're in level 3, read your own proc, only level 3's NSpid info > will be shown. No parent namesapces info could be seen. D'oh! Sorry, I see, you're starting at ns->level. And ns is the ns of the proc mount, not the caller. that looks good. So Acked-by: Serge Hallyn <serge.hallyn@xxxxxxxxxxxxx> > Only if not providing a procfs mount point for the new container, > and without a proper pivot_root, > we could see some NSpid info of parent ns. > > If each new container got their own procfs mount point, > only its and its child's NSpid info could be seen. > > > > > Now it may be fair to say "this is proc, and proc and sys show > > host info which is not containerized and cannot be checkpointed > > and restarted, deal with it." But I'm not sure. > > > > There are two ways you could deal with this. One would be to > > show the nspids only to the level of the reader of the file - but > > I don't think you need to do that. I think you're better off > > simply showing the pids up to the level of the struct pid for > > the mounter of the procfs. So if I'm inside container c2 which > > is inside container c1, my own /proc will only show pids which > > are valid in c2 (and any child namespaces), while the /proc > > mounted in c1 will show pids valid in c1 and c2 (and any children), > > but not those in the init_pid_ns. It's then just up to the > > container administrators to make sure that c2 cannot see c1's > > /proc to confuse itself and confuddle checkpoint-restart > > IIUC, this patch already deal with this scenario: > > + for (g = ns->level; g <= pid->level; g++) > + seq_printf(m, "\t%d ", > + task_tgid_nr_ns(p, pid->numbers[g].ns)); > > With this patch, it did like > a) in init_pid_ns, check /proc/21776/status > NStgid: 21776 5 1 > > b) in c1, check /proc/5/status: > NStgid: 5 1 > > c) in c2, check /proc/1/status: > NStgid: 1 > > Thanks, > - Chen _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/containers
