From mboxrd@z Thu Jan 1 00:00:00 1970 From: ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org (Eric W. Biederman) Subject: Re: [Resend][PATCH] ns,proc: introduce pid_in_ns Date: Fri, 25 Apr 2014 12:17:33 -0700 Message-ID: <87a9b95icy.fsf@x220.int.ebiederm.org> References: <1398415405-19872-1-git-send-email-chenhanxiao@cn.fujitsu.com> <20140425185645.GA10637@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20140425185645.GA10637-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> (Oleg Nesterov's message of "Fri, 25 Apr 2014 20:56:45 +0200") List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: containers-bounces-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org Errors-To: containers-bounces-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org To: Oleg Nesterov Cc: containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org, Serge Hallyn , linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, David Howells , Al Viro , Andrew Morton List-Id: containers.vger.kernel.org Oleg Nesterov writes: > On 04/25, Chen Hanxiao wrote: >> >> We lacked of convenient method of getting the pid inside containers. Are unix domain sockets not convinient? >> 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 ... Eric