> -----Original Message----- > From: Eric W. Biederman [mailto:ebiederm@xxxxxxxxxxxx] > Sent: Saturday, April 26, 2014 3:18 AM > To: Oleg Nesterov > Cc: Chen, Hanxiao/陈 晗霄; containers@xxxxxxxxxxxxxxxxxxxxxxxxxx; > linux-kernel@xxxxxxxxxxxxxxx; Andrew Morton; Serge Hallyn; Daniel P. Berrange; > Al Viro; David Howells > Subject: Re: [Resend][PATCH] ns,proc: introduce pid_in_ns > > Oleg Nesterov <oleg@xxxxxxxxxx> writes: > > > On 04/25, Chen Hanxiao wrote: > >> > >> We lacked of convenient method of getting the pid inside containers. > > Are unix domain sockets not convinient? > It's a very good method, but not so directly for just pid translation. > >> If some issues occurred inside container guest, host user > >> could not know which process is in trouble just by guest pid: > >> the users of container guest only knew the pid inside containers. > >> This will bring obstacle for trouble shooting. > >> > >> This patch introduces pid_in_ns: > >> If one process is in init_pid_ns, /proc/PID/pid_in_ns > >> equals to /proc/PID; > >> if one process is in pidns, /proc/PID/pid_in_ns > >> will tell the pid inside containers; > >> if pidns is nested, it depends on which pidns are you in. > > > > Yes another /proc/pid/ file... > > > > Perhaps it would be better to change /proc/pid/status["Pid:"] to report the > > list of pid_nr's, from its namespace up to the observer's namespace. The same > > for "Tgid:". > > > > (Hmm. And why "Ngid:" was inserted between tid and tgid ?) > > Add to that Ngid has a completely hosed implementation. It is a pid > stored in a pid_t, not a struct pid *. Sigh. > > I am getting more and more tempted to obliterate task->pid. It just > encourages bad code. > > >> +int proc_pid_in_ns(struct seq_file *m, struct pid_namespace *ns, > >> + struct pid *pid, struct task_struct *task) > >> +{ > >> + pid_t pid_in_ns; > >> + unsigned int level; > >> + > >> + level = pid->level; > >> + pid_in_ns = task_pid_nr_ns(task, pid->numbers[level].ns); > > > > This looks overcomplicated or I missed something? > > I do think if we care we need to print the entire set of pids. > I don't know if /proc/pid/status is the proper place but ... > Let's print the entire set of pids in /proc/pid/status. > Eric Thanks for the comments. v2 will come soon. - Chen _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/containers
