[PATCH] workqueue: fix a typo
s/detemined/determined Signed-off-by: Chen Hanxiao --- kernel/workqueue.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/kernel/workqueue.c b/kernel/workqueue.c index 586ad91..1a092e1 100644 --- a/kernel/workqueue.c +++ b/kernel/workqueue.c @@ -2616,7 +2616,7 @@ EXPORT_SYMBOL_GPL(flush_workqueue); * Wait until the workqueue becomes empty. While draining is in progress, * only chain queueing is allowed. IOW, only currently pending or running * work items on @wq can queue further work items on it. @wq is flushed - * repeatedly until it becomes empty. The number of flushing is detemined + * repeatedly until it becomes empty. The number of flushing is determined * by the depth of chaining and should be relatively short. Whine if it * takes too long. */ -- 2.1.0 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] workqueue: fix a typo
s/detemined/determined Signed-off-by: Chen Hanxiao chenhanx...@cn.fujitsu.com --- kernel/workqueue.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/kernel/workqueue.c b/kernel/workqueue.c index 586ad91..1a092e1 100644 --- a/kernel/workqueue.c +++ b/kernel/workqueue.c @@ -2616,7 +2616,7 @@ EXPORT_SYMBOL_GPL(flush_workqueue); * Wait until the workqueue becomes empty. While draining is in progress, * only chain queueing is allowed. IOW, only currently pending or running * work items on @wq can queue further work items on it. @wq is flushed - * repeatedly until it becomes empty. The number of flushing is detemined + * repeatedly until it becomes empty. The number of flushing is determined * by the depth of chaining and should be relatively short. Whine if it * takes too long. */ -- 2.1.0 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2] docs: add VmPMD description in proc
commit dc6c9a35b66b ("mm: account pmd page tables to the process")
add VmPMD in /proc/PID/status.
This patch add a description in proc.txt for it.
cc: Kirill A. Shutemov
Signed-off-by: Chen Hanxiao
---
v2: change description of VmPMD as Kirill's comment
Documentation/filesystems/proc.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/filesystems/proc.txt
b/Documentation/filesystems/proc.txt
index c3b6b30..e8aba97 100644
--- a/Documentation/filesystems/proc.txt
+++ b/Documentation/filesystems/proc.txt
@@ -235,6 +235,7 @@ Table 1-2: Contents of the status files (as of 3.20.0)
VmExe size of text segment
VmLib size of shared library code
VmPTE size of page table entries
+ VmPMD size of second level page tables
VmSwap size of swap usage (the number of referred
swapents)
Threads number of threads
SigQnumber of signals queued/max. number for queue
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] docs: add VmPMD description in proc
> -Original Message-
> From: Kirill A. Shutemov [mailto:kir...@shutemov.name]
> Sent: Friday, April 24, 2015 2:33 PM
> To: Chen, Hanxiao/陈 晗霄
> Cc: Jonathan Corbet; linux-...@vger.kernel.org; linux-kernel@vger.kernel.org;
> Kirill A. Shutemov
> Subject: Re: [PATCH] docs: add VmPMD description in proc
>
> On Fri, Apr 24, 2015 at 02:24:32AM -0400, Chen Hanxiao wrote:
> > commit dc6c9a35b66b ("mm: account pmd page tables to the process")
> > add VmPMD in /proc/PID/status.
> > This patch add a description in proc.txt for it.
> >
> > cc: Kirill A. Shutemov
> > Signed-off-by: Chen Hanxiao
> > ---
> > Documentation/filesystems/proc.txt | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/Documentation/filesystems/proc.txt
> b/Documentation/filesystems/proc.txt
> > index c3b6b30..e8aba97 100644
> > --- a/Documentation/filesystems/proc.txt
> > +++ b/Documentation/filesystems/proc.txt
> > @@ -235,6 +235,7 @@ Table 1-2: Contents of the status files (as of 3.20.0)
> > VmExe size of text segment
> > VmLib size of shared library code
> > VmPTE size of page table entries
> > + VmPMD size of page middle directory
>
> size of second level page tables
>
> ?
For we may have various page levels,
'second level' is more accurate than 'middle'.
Thanks for the review.
v2 will come soon.
Regards,
- Chen
>
> > VmSwap size of swap usage (the number of referred
> > swapents)
> > Threads number of threads
> > SigQnumber of signals queued/max. number for queue
> > --
> > 2.1.0
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> > the body of a message to majord...@vger.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
> > Please read the FAQ at http://www.tux.org/lkml/
>
> --
> Kirill A. Shutemov
N�Р骒r��yb�X�肚�v�^�)藓{.n�+�伐�{��赙zXФ�≤�}��财�z�:+v�����赙zZ+��+zf＂�h���~i���z� �wア�?�ㄨ��&�)撷f��^j谦y�m��@A�a囤�
0鹅h���i
[PATCH] docs: add VmPMD description in proc
commit dc6c9a35b66b ("mm: account pmd page tables to the process")
add VmPMD in /proc/PID/status.
This patch add a description in proc.txt for it.
cc: Kirill A. Shutemov
Signed-off-by: Chen Hanxiao
---
Documentation/filesystems/proc.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/filesystems/proc.txt
b/Documentation/filesystems/proc.txt
index c3b6b30..e8aba97 100644
--- a/Documentation/filesystems/proc.txt
+++ b/Documentation/filesystems/proc.txt
@@ -235,6 +235,7 @@ Table 1-2: Contents of the status files (as of 3.20.0)
VmExe size of text segment
VmLib size of shared library code
VmPTE size of page table entries
+ VmPMD size of page middle directory
VmSwap size of swap usage (the number of referred
swapents)
Threads number of threads
SigQnumber of signals queued/max. number for queue
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] docs: add VmPMD description in proc
commit dc6c9a35b66b (mm: account pmd page tables to the process) add VmPMD in /proc/PID/status. This patch add a description in proc.txt for it. cc: Kirill A. Shutemov kirill.shute...@linux.intel.com Signed-off-by: Chen Hanxiao chenhanx...@cn.fujitsu.com --- Documentation/filesystems/proc.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/filesystems/proc.txt b/Documentation/filesystems/proc.txt index c3b6b30..e8aba97 100644 --- a/Documentation/filesystems/proc.txt +++ b/Documentation/filesystems/proc.txt @@ -235,6 +235,7 @@ Table 1-2: Contents of the status files (as of 3.20.0) VmExe size of text segment VmLib size of shared library code VmPTE size of page table entries + VmPMD size of page middle directory VmSwap size of swap usage (the number of referred swapents) Threads number of threads SigQnumber of signals queued/max. number for queue -- 2.1.0 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] docs: add VmPMD description in proc
-Original Message-
From: Kirill A. Shutemov [mailto:kir...@shutemov.name]
Sent: Friday, April 24, 2015 2:33 PM
To: Chen, Hanxiao/陈 晗霄
Cc: Jonathan Corbet; linux-...@vger.kernel.org; linux-kernel@vger.kernel.org;
Kirill A. Shutemov
Subject: Re: [PATCH] docs: add VmPMD description in proc
On Fri, Apr 24, 2015 at 02:24:32AM -0400, Chen Hanxiao wrote:
commit dc6c9a35b66b (mm: account pmd page tables to the process)
add VmPMD in /proc/PID/status.
This patch add a description in proc.txt for it.
cc: Kirill A. Shutemov kirill.shute...@linux.intel.com
Signed-off-by: Chen Hanxiao chenhanx...@cn.fujitsu.com
---
Documentation/filesystems/proc.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/filesystems/proc.txt
b/Documentation/filesystems/proc.txt
index c3b6b30..e8aba97 100644
--- a/Documentation/filesystems/proc.txt
+++ b/Documentation/filesystems/proc.txt
@@ -235,6 +235,7 @@ Table 1-2: Contents of the status files (as of 3.20.0)
VmExe size of text segment
VmLib size of shared library code
VmPTE size of page table entries
+ VmPMD size of page middle directory
size of second level page tables
?
For we may have various page levels,
'second level' is more accurate than 'middle'.
Thanks for the review.
v2 will come soon.
Regards,
- Chen
VmSwap size of swap usage (the number of referred
swapents)
Threads number of threads
SigQnumber of signals queued/max. number for queue
--
2.1.0
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
--
Kirill A. Shutemov
N�Р骒r��yb�X�肚�v�^�)藓{.n�+�伐�{��赙zXФ�≤�}��财�z�j:+v�����赙zZ+��+zf＂�h���~i���z� �wア�?�ㄨ���)撷f��^j谦y�m��@A�a囤�
0鹅h���i
[PATCH v2] docs: add VmPMD description in proc
commit dc6c9a35b66b (mm: account pmd page tables to the process) add VmPMD in /proc/PID/status. This patch add a description in proc.txt for it. cc: Kirill A. Shutemov kirill.shute...@linux.intel.com Signed-off-by: Chen Hanxiao chenhanx...@cn.fujitsu.com --- v2: change description of VmPMD as Kirill's comment Documentation/filesystems/proc.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/filesystems/proc.txt b/Documentation/filesystems/proc.txt index c3b6b30..e8aba97 100644 --- a/Documentation/filesystems/proc.txt +++ b/Documentation/filesystems/proc.txt @@ -235,6 +235,7 @@ Table 1-2: Contents of the status files (as of 3.20.0) VmExe size of text segment VmLib size of shared library code VmPTE size of page table entries + VmPMD size of second level page tables VmSwap size of swap usage (the number of referred swapents) Threads number of threads SigQnumber of signals queued/max. number for queue -- 2.1.0 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] Docs: proc: fix kernel version
Hi,
> -Original Message-
> From: Jonathan Corbet [mailto:cor...@lwn.net]
> Sent: Tuesday, April 21, 2015 8:14 PM
> To: Chen, Hanxiao/陈 晗霄
> Cc: Andrew Morton; Nathan Scott; linux-...@vger.kernel.org;
> linux-kernel@vger.kernel.org; Jiri Kosina
> Subject: Re: [PATCH] Docs: proc: fix kernel version
>
> On Mon, 20 Apr 2015 22:48:23 -0400
> Chen Hanxiao wrote:
>
> Thank you for working to update the documentation! That said, though, I
> have a question and a request with regard to this particular change.
>
> > -Table 1-2: Contents of the status files (as of 3.20.0)
> > +Table 1-2: Contents of the status files (as of 4.1)
>
> That file is full of weird version numbers; is there a reason why you want
> to change that one in particular? The 2.6.8-rc3 reference immediately
> afterward doesn't seem more worthy of protection.
>
commit 15eb42d674de8da66950f78b5c7202accabe026e
had updated Table 1-2 in this doc.
When we posted it, we thought it's for in 3.20.
Now it comes to mainline from mm tree, it's 4.1 now.
So I think we need a surplus patch for it.
Also, patch Reviewed-by: Nathan Scott
> This file is dramatically out of date in general. Rather than change the
> version number at the head of the list of status files, why not update the
> list to match current reality? There are a lot of things missing.
>
> Failing that, I would entertain a patch that simply removes most of the
> version numbers from this file; I don't think they provide any useful
> information, and I certainly don't see the value of occasionally tweaking
> them forward.
Before someone could be able to update the whole file,
keeping version numbers still help.
Regards,
- Chen
>
> Thanks,
>
> jon
N�Р骒r��yb�X�肚�v�^�)藓{.n�+�伐�{��赙zXФ�≤�}��财�z�:+v�����赙zZ+��+zf＂�h���~i���z� �wア�?�ㄨ��&�)撷f��^j谦y�m��@A�a囤�
0鹅h���i
RE: [PATCH] Docs: proc: fix kernel version
Hi,
-Original Message-
From: Jonathan Corbet [mailto:cor...@lwn.net]
Sent: Tuesday, April 21, 2015 8:14 PM
To: Chen, Hanxiao/陈 晗霄
Cc: Andrew Morton; Nathan Scott; linux-...@vger.kernel.org;
linux-kernel@vger.kernel.org; Jiri Kosina
Subject: Re: [PATCH] Docs: proc: fix kernel version
On Mon, 20 Apr 2015 22:48:23 -0400
Chen Hanxiao chenhanx...@cn.fujitsu.com wrote:
Thank you for working to update the documentation! That said, though, I
have a question and a request with regard to this particular change.
-Table 1-2: Contents of the status files (as of 3.20.0)
+Table 1-2: Contents of the status files (as of 4.1)
That file is full of weird version numbers; is there a reason why you want
to change that one in particular? The 2.6.8-rc3 reference immediately
afterward doesn't seem more worthy of protection.
commit 15eb42d674de8da66950f78b5c7202accabe026e
had updated Table 1-2 in this doc.
When we posted it, we thought it's for in 3.20.
Now it comes to mainline from mm tree, it's 4.1 now.
So I think we need a surplus patch for it.
Also, patch Reviewed-by: Nathan Scott nath...@redhat.com
This file is dramatically out of date in general. Rather than change the
version number at the head of the list of status files, why not update the
list to match current reality? There are a lot of things missing.
Failing that, I would entertain a patch that simply removes most of the
version numbers from this file; I don't think they provide any useful
information, and I certainly don't see the value of occasionally tweaking
them forward.
Before someone could be able to update the whole file,
keeping version numbers still help.
Regards,
- Chen
Thanks,
jon
N�Р骒r��yb�X�肚�v�^�)藓{.n�+�伐�{��赙zXФ�≤�}��财�z�j:+v�����赙zZ+��+zf＂�h���~i���z� �wア�?�ㄨ���)撷f��^j谦y�m��@A�a囤�
0鹅h���i
[PATCH] Docs: proc: fix kernel version
Change kernel version from 3.20 to 4.1 Signed-off-by: Chen Hanxiao --- Documentation/filesystems/proc.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/filesystems/proc.txt b/Documentation/filesystems/proc.txt index c3b6b30..1cc7155 100644 --- a/Documentation/filesystems/proc.txt +++ b/Documentation/filesystems/proc.txt @@ -205,7 +205,7 @@ asynchronous manner and the value may not be very precise. To see a precise snapshot of a moment, you can see /proc//smaps file and scan page table. It's slow but very precise. -Table 1-2: Contents of the status files (as of 3.20.0) +Table 1-2: Contents of the status files (as of 4.1) .. Field Content Namefilename of the executable -- 2.1.0 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Docs: proc: fix kernel version
Change kernel version from 3.20 to 4.1 Signed-off-by: Chen Hanxiao chenhanx...@cn.fujitsu.com --- Documentation/filesystems/proc.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/filesystems/proc.txt b/Documentation/filesystems/proc.txt index c3b6b30..1cc7155 100644 --- a/Documentation/filesystems/proc.txt +++ b/Documentation/filesystems/proc.txt @@ -205,7 +205,7 @@ asynchronous manner and the value may not be very precise. To see a precise snapshot of a moment, you can see /proc/pid/smaps file and scan page table. It's slow but very precise. -Table 1-2: Contents of the status files (as of 3.20.0) +Table 1-2: Contents of the status files (as of 4.1) .. Field Content Namefilename of the executable -- 2.1.0 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH v10 2/2] docs: add missing and new /proc/PID/status file entries, fix typos
> -Original Message- > From: Andrew Morton [mailto:a...@linux-foundation.org] > Sent: Tuesday, February 24, 2015 5:02 AM > To: Chen, Hanxiao/陈 晗霄 > Cc: Eric W. Biederman; contain...@lists.linux-foundation.org; > linux-kernel@vger.kernel.org; linux-...@vger.kernel.org; Serge Hallyn; > Jonathan > Corbet; Gui, Jianfeng/归 剑峰; Nathan Scott > Subject: Re: [PATCH v10 2/2] docs: add missing and new /proc/PID/status file > entries, > fix typos > > On Fri, 6 Feb 2015 18:45:50 +0800 Chen Hanxiao > wrote: > > > From: Nathan Scott > > > > From: Nathan Scott > > > > docs: add missing and new /proc/PID/status file entries, fix typos > > > > Signed-off-by: Nathan Scott > > This should have had your signoff, because you were on the patch > delivery path (Documentation/SubmittingPatches section 11 has details). > > I have made that change to my copy of this patch. Hi, Thanks for your help. I'll be more careful next time. Thank you very much. Regards, - Chen
RE: [PATCH v10 2/2] docs: add missing and new /proc/PID/status file entries, fix typos
-Original Message- From: Andrew Morton [mailto:a...@linux-foundation.org] Sent: Tuesday, February 24, 2015 5:02 AM To: Chen, Hanxiao/陈 晗霄 Cc: Eric W. Biederman; contain...@lists.linux-foundation.org; linux-kernel@vger.kernel.org; linux-...@vger.kernel.org; Serge Hallyn; Jonathan Corbet; Gui, Jianfeng/归 剑峰; Nathan Scott Subject: Re: [PATCH v10 2/2] docs: add missing and new /proc/PID/status file entries, fix typos On Fri, 6 Feb 2015 18:45:50 +0800 Chen Hanxiao chenhanx...@cn.fujitsu.com wrote: From: Nathan Scott nath...@redhat.com From: Nathan Scott nath...@redhat.com docs: add missing and new /proc/PID/status file entries, fix typos Signed-off-by: Nathan Scott nath...@redhat.com This should have had your signoff, because you were on the patch delivery path (Documentation/SubmittingPatches section 11 has details). I have made that change to my copy of this patch. Hi, Thanks for your help. I'll be more careful next time. Thank you very much. Regards, - Chen
[PATCH v10 2/2] docs: add missing and new /proc/PID/status file entries, fix typos
From: Nathan Scott --- Documentation/filesystems/proc.txt | 11 --- 1 file changed, 8 insertions(+), 3 deletions(-) diff --git a/Documentation/filesystems/proc.txt b/Documentation/filesystems/proc.txt index a07ba61..6d37062 100644 --- a/Documentation/filesystems/proc.txt +++ b/Documentation/filesystems/proc.txt @@ -200,12 +200,12 @@ contains details information about the process itself. Its fields are explained in Table 1-4. (for SMP CONFIG users) -For making accounting scalable, RSS related information are handled in -asynchronous manner and the vaule may not be very precise. To see a precise +For making accounting scalable, RSS related information are handled in an +asynchronous manner and the value may not be very precise. To see a precise snapshot of a moment, you can see /proc//smaps file and scan page table. It's slow but very precise. -Table 1-2: Contents of the status files (as of 2.6.30-rc7) +Table 1-2: Contents of the status files (as of 3.20.0) .. Field Content Namefilename of the executable @@ -213,6 +213,7 @@ Table 1-2: Contents of the status files (as of 2.6.30-rc7) in an uninterruptible wait, Z is zombie, T is traced or stopped) Tgidthread group ID + NgidNUMA group ID (0 if none) Pid process id PPidprocess id of the parent process TracerPid PID of process tracing this process (0 if not) @@ -220,6 +221,10 @@ Table 1-2: Contents of the status files (as of 2.6.30-rc7) Gid Real, effective, saved set, and file system GIDs FDSize number of file descriptor slots currently allocated Groups supplementary group list + NStgid descendant namespace thread group ID hierarchy + NSpid descendant namespace process ID hierarchy + NSpgid descendant namespace process group ID hierarchy + NSsid descendant namespace session ID hierarchy VmPeak peak virtual memory size VmSize total program size VmLck locked memory size -- 2.1.0 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[resend][PATCH v10 1/2] /proc/PID/status: show all sets of pid according to ns
If some issues occurred inside a 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 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 Acked-by: Serge Hallyn Acked-by: "Eric W. Biederman" Tested-by: Serge Hallyn Tested-by: Nathan Scott Signed-off-by: Chen Hanxiao --- v10: remove trailing space of pid numbers rebased on 3.19 v9: rebased on 3.19-rc1 No change from v4-v8 v3: add another two fielsd: NSpgid and NSsid. v2: add two new fields: NStgid and NSpid. keep fields of Tgid and Pid unchanged for back compatibility. fs/proc/array.c | 16 1 file changed, 16 insertions(+) diff --git a/fs/proc/array.c b/fs/proc/array.c index 1295a00..d79bad9 100644 --- a/fs/proc/array.c +++ b/fs/proc/array.c @@ -188,6 +188,22 @@ static inline void task_state(struct seq_file *m, struct pid_namespace *ns, from_kgid_munged(user_ns, GROUP_AT(group_info, g))); put_cred(cred); + seq_puts(m, "\nNStgid:"); + for (g = ns->level; g <= pid->level; g++) + seq_printf(m, "\t%d", + task_tgid_nr_ns(p, pid->numbers[g].ns)); + seq_puts(m, "\nNSpid:"); + for (g = ns->level; g <= pid->level; g++) + seq_printf(m, "\t%d", + task_pid_nr_ns(p, pid->numbers[g].ns)); + seq_puts(m, "\nNSpgid:"); + for (g = ns->level; g <= pid->level; g++) + seq_printf(m, "\t%d", + task_pgrp_nr_ns(p, pid->numbers[g].ns)); + seq_puts(m, "\nNSsid:"); + for (g = ns->level; g <= pid->level; g++) + seq_printf(m, "\t%d", + task_session_nr_ns(p, pid->numbers[g].ns)); seq_putc(m, '\n'); } -- 2.1.0 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[resend][PATCH v10 0/2] ns, procfs: pid conversion between ns
Chen Hanxiao (1): /proc/PID/status: show all sets of pid according to ns Nathan Scott (1): docs: add missing and new /proc/PID/status file entries, fix typos Documentation/filesystems/proc.txt | 11 --- fs/proc/array.c| 16 2 files changed, 24 insertions(+), 3 deletions(-) -- 2.1.0 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[resend][PATCH v10 1/2] /proc/PID/status: show all sets of pid according to ns
If some issues occurred inside a 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 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 Acked-by: Serge Hallyn serge.hal...@canonical.com Acked-by: Eric W. Biederman ebied...@xmission.com Tested-by: Serge Hallyn serge.hal...@canonical.com Tested-by: Nathan Scott nath...@redhat.com Signed-off-by: Chen Hanxiao chenhanx...@cn.fujitsu.com --- v10: remove trailing space of pid numbers rebased on 3.19 v9: rebased on 3.19-rc1 No change from v4-v8 v3: add another two fielsd: NSpgid and NSsid. v2: add two new fields: NStgid and NSpid. keep fields of Tgid and Pid unchanged for back compatibility. fs/proc/array.c | 16 1 file changed, 16 insertions(+) diff --git a/fs/proc/array.c b/fs/proc/array.c index 1295a00..d79bad9 100644 --- a/fs/proc/array.c +++ b/fs/proc/array.c @@ -188,6 +188,22 @@ static inline void task_state(struct seq_file *m, struct pid_namespace *ns, from_kgid_munged(user_ns, GROUP_AT(group_info, g))); put_cred(cred); + seq_puts(m, \nNStgid:); + for (g = ns-level; g = pid-level; g++) + seq_printf(m, \t%d, + task_tgid_nr_ns(p, pid-numbers[g].ns)); + seq_puts(m, \nNSpid:); + for (g = ns-level; g = pid-level; g++) + seq_printf(m, \t%d, + task_pid_nr_ns(p, pid-numbers[g].ns)); + seq_puts(m, \nNSpgid:); + for (g = ns-level; g = pid-level; g++) + seq_printf(m, \t%d, + task_pgrp_nr_ns(p, pid-numbers[g].ns)); + seq_puts(m, \nNSsid:); + for (g = ns-level; g = pid-level; g++) + seq_printf(m, \t%d, + task_session_nr_ns(p, pid-numbers[g].ns)); seq_putc(m, '\n'); } -- 2.1.0 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v10 2/2] docs: add missing and new /proc/PID/status file entries, fix typos
From: Nathan Scott nath...@redhat.com --- Documentation/filesystems/proc.txt | 11 --- 1 file changed, 8 insertions(+), 3 deletions(-) diff --git a/Documentation/filesystems/proc.txt b/Documentation/filesystems/proc.txt index a07ba61..6d37062 100644 --- a/Documentation/filesystems/proc.txt +++ b/Documentation/filesystems/proc.txt @@ -200,12 +200,12 @@ contains details information about the process itself. Its fields are explained in Table 1-4. (for SMP CONFIG users) -For making accounting scalable, RSS related information are handled in -asynchronous manner and the vaule may not be very precise. To see a precise +For making accounting scalable, RSS related information are handled in an +asynchronous manner and the value may not be very precise. To see a precise snapshot of a moment, you can see /proc/pid/smaps file and scan page table. It's slow but very precise. -Table 1-2: Contents of the status files (as of 2.6.30-rc7) +Table 1-2: Contents of the status files (as of 3.20.0) .. Field Content Namefilename of the executable @@ -213,6 +213,7 @@ Table 1-2: Contents of the status files (as of 2.6.30-rc7) in an uninterruptible wait, Z is zombie, T is traced or stopped) Tgidthread group ID + NgidNUMA group ID (0 if none) Pid process id PPidprocess id of the parent process TracerPid PID of process tracing this process (0 if not) @@ -220,6 +221,10 @@ Table 1-2: Contents of the status files (as of 2.6.30-rc7) Gid Real, effective, saved set, and file system GIDs FDSize number of file descriptor slots currently allocated Groups supplementary group list + NStgid descendant namespace thread group ID hierarchy + NSpid descendant namespace process ID hierarchy + NSpgid descendant namespace process group ID hierarchy + NSsid descendant namespace session ID hierarchy VmPeak peak virtual memory size VmSize total program size VmLck locked memory size -- 2.1.0 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[resend][PATCH v10 0/2] ns, procfs: pid conversion between ns
Chen Hanxiao (1): /proc/PID/status: show all sets of pid according to ns Nathan Scott (1): docs: add missing and new /proc/PID/status file entries, fix typos Documentation/filesystems/proc.txt | 11 --- fs/proc/array.c| 16 2 files changed, 24 insertions(+), 3 deletions(-) -- 2.1.0 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH v10 0/2] ns, procfs: pid conversion between ns
> -Original Message- > From: Chen, Hanxiao/陈 晗霄 > Sent: Wednesday, February 11, 2015 1:52 PM > > > -Original Message- > > From: containers-boun...@lists.linux-foundation.org > > > > Chen Hanxiao (1): > > /proc/PID/status: show all sets of pid according to ns > > > > Nathan Scott (1): > > docs: add missing and new /proc/PID/status file entries, fix typos > > > > Documentation/filesystems/proc.txt | 11 --- > > fs/proc/array.c| 16 > > 2 files changed, 24 insertions(+), 3 deletions(-) > > > > Hi Eric, > > Could please pick this series up for 3.20? > Hi Andrew, Since the patch is already Acked by Eric, Serge and Tested by Serge and Nathan. Would you please take this series for 3.20? It's already half a year since we posted the patch for the first time, and rebased several times. That's really frustrating. We hope this patch can be merged in this cycle. Thanks, - Chen
RE: [PATCH v10 0/2] ns, procfs: pid conversion between ns
-Original Message- From: Chen, Hanxiao/陈 晗霄 Sent: Wednesday, February 11, 2015 1:52 PM -Original Message- From: containers-boun...@lists.linux-foundation.org Chen Hanxiao (1): /proc/PID/status: show all sets of pid according to ns Nathan Scott (1): docs: add missing and new /proc/PID/status file entries, fix typos Documentation/filesystems/proc.txt | 11 --- fs/proc/array.c| 16 2 files changed, 24 insertions(+), 3 deletions(-) Hi Eric, Could please pick this series up for 3.20? Hi Andrew, Since the patch is already Acked by Eric, Serge and Tested by Serge and Nathan. Would you please take this series for 3.20? It's already half a year since we posted the patch for the first time, and rebased several times. That's really frustrating. We hope this patch can be merged in this cycle. Thanks, - Chen
RE: [PATCH v10 0/2] ns, procfs: pid conversion between ns
> -Original Message- > From: containers-boun...@lists.linux-foundation.org > [mailto:containers-boun...@lists.linux-foundation.org] On Behalf Of Chen > Hanxiao > Sent: Friday, February 06, 2015 6:46 PM > To: Eric W. Biederman; Andrew Morton > Cc: Jonathan Corbet; contain...@lists.linux-foundation.org; Serge Hallyn; > linux-...@vger.kernel.org; linux-kernel@vger.kernel.org; Nathan Scott > Subject: [PATCH v10 0/2] ns, procfs: pid conversion between ns > > > Chen Hanxiao (1): > /proc/PID/status: show all sets of pid according to ns > > Nathan Scott (1): > docs: add missing and new /proc/PID/status file entries, fix typos > > Documentation/filesystems/proc.txt | 11 --- > fs/proc/array.c| 16 > 2 files changed, 24 insertions(+), 3 deletions(-) > Hi Eric, Could please pick this series up for 3.20? Thanks, - Chen
RE: [PATCH v10 0/2] ns, procfs: pid conversion between ns
-Original Message- From: containers-boun...@lists.linux-foundation.org [mailto:containers-boun...@lists.linux-foundation.org] On Behalf Of Chen Hanxiao Sent: Friday, February 06, 2015 6:46 PM To: Eric W. Biederman; Andrew Morton Cc: Jonathan Corbet; contain...@lists.linux-foundation.org; Serge Hallyn; linux-...@vger.kernel.org; linux-kernel@vger.kernel.org; Nathan Scott Subject: [PATCH v10 0/2] ns, procfs: pid conversion between ns Chen Hanxiao (1): /proc/PID/status: show all sets of pid according to ns Nathan Scott (1): docs: add missing and new /proc/PID/status file entries, fix typos Documentation/filesystems/proc.txt | 11 --- fs/proc/array.c| 16 2 files changed, 24 insertions(+), 3 deletions(-) Hi Eric, Could please pick this series up for 3.20? Thanks, - Chen
[PATCH v10 1/2] /proc/PID/status: show all sets of pid according to ns
If some issues occurred inside a 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 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 Acked-by: Serge Hallyn Acked-by: "Eric W. Biederman" Tested-by: Serge Hallyn Tested-by: Nathan Scott Signed-off-by: Chen Hanxiao --- v10: remove trailing space of pid numbers "\t%d " -> "\t%d", rebased on 3.19-rc7 v9: rebased on 3.19-rc1 No change from v4-v8 v3: add another two fielsd: NSpgid and NSsid. v2: add two new fields: NStgid and NSpid. keep fields of Tgid and Pid unchanged for back compatibility. fs/proc/array.c | 16 1 file changed, 16 insertions(+) diff --git a/fs/proc/array.c b/fs/proc/array.c index bd117d0..f3e6d76 100644 --- a/fs/proc/array.c +++ b/fs/proc/array.c @@ -208,6 +208,22 @@ static inline void task_state(struct seq_file *m, struct pid_namespace *ns, from_kgid_munged(user_ns, GROUP_AT(group_info, g))); put_cred(cred); + seq_puts(m, "\nNStgid:"); + for (g = ns->level; g <= pid->level; g++) + seq_printf(m, "\t%d", + task_tgid_nr_ns(p, pid->numbers[g].ns)); + seq_puts(m, "\nNSpid:"); + for (g = ns->level; g <= pid->level; g++) + seq_printf(m, "\t%d", + task_pid_nr_ns(p, pid->numbers[g].ns)); + seq_puts(m, "\nNSpgid:"); + for (g = ns->level; g <= pid->level; g++) + seq_printf(m, "\t%d", + task_pgrp_nr_ns(p, pid->numbers[g].ns)); + seq_puts(m, "\nNSsid:"); + for (g = ns->level; g <= pid->level; g++) + seq_printf(m, "\t%d", + task_session_nr_ns(p, pid->numbers[g].ns)); seq_putc(m, '\n'); } -- 2.1.0 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v10 2/2] docs: add missing and new /proc/PID/status file entries, fix typos
From: Nathan Scott From: Nathan Scott docs: add missing and new /proc/PID/status file entries, fix typos Signed-off-by: Nathan Scott --- Documentation/filesystems/proc.txt | 11 --- 1 file changed, 8 insertions(+), 3 deletions(-) diff --git a/Documentation/filesystems/proc.txt b/Documentation/filesystems/proc.txt index aae9dd1..457cebd 100644 --- a/Documentation/filesystems/proc.txt +++ b/Documentation/filesystems/proc.txt @@ -197,12 +197,12 @@ contains details information about the process itself. Its fields are explained in Table 1-4. (for SMP CONFIG users) -For making accounting scalable, RSS related information are handled in -asynchronous manner and the vaule may not be very precise. To see a precise +For making accounting scalable, RSS related information are handled in an +asynchronous manner and the value may not be very precise. To see a precise snapshot of a moment, you can see /proc//smaps file and scan page table. It's slow but very precise. -Table 1-2: Contents of the status files (as of 2.6.30-rc7) +Table 1-2: Contents of the status files (as of 3.20.0) .. Field Content Namefilename of the executable @@ -210,6 +210,7 @@ Table 1-2: Contents of the status files (as of 2.6.30-rc7) in an uninterruptible wait, Z is zombie, T is traced or stopped) Tgidthread group ID + NgidNUMA group ID (0 if none) Pid process id PPidprocess id of the parent process TracerPid PID of process tracing this process (0 if not) @@ -217,6 +218,10 @@ Table 1-2: Contents of the status files (as of 2.6.30-rc7) Gid Real, effective, saved set, and file system GIDs FDSize number of file descriptor slots currently allocated Groups supplementary group list + NStgid descendant namespace thread group ID hierarchy + NSpid descendant namespace process ID hierarchy + NSpgid descendant namespace process group ID hierarchy + NSsid descendant namespace session ID hierarchy VmPeak peak virtual memory size VmSize total program size VmLck locked memory size -- 2.1.0 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v10 0/2] ns, procfs: pid conversion between ns
Chen Hanxiao (1): /proc/PID/status: show all sets of pid according to ns Nathan Scott (1): docs: add missing and new /proc/PID/status file entries, fix typos Documentation/filesystems/proc.txt | 11 --- fs/proc/array.c| 16 2 files changed, 24 insertions(+), 3 deletions(-) -- 2.1.0 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v10 0/2] ns, procfs: pid conversion between ns
Chen Hanxiao (1): /proc/PID/status: show all sets of pid according to ns Nathan Scott (1): docs: add missing and new /proc/PID/status file entries, fix typos Documentation/filesystems/proc.txt | 11 --- fs/proc/array.c| 16 2 files changed, 24 insertions(+), 3 deletions(-) -- 2.1.0 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v10 2/2] docs: add missing and new /proc/PID/status file entries, fix typos
From: Nathan Scott nath...@redhat.com From: Nathan Scott nath...@redhat.com docs: add missing and new /proc/PID/status file entries, fix typos Signed-off-by: Nathan Scott nath...@redhat.com --- Documentation/filesystems/proc.txt | 11 --- 1 file changed, 8 insertions(+), 3 deletions(-) diff --git a/Documentation/filesystems/proc.txt b/Documentation/filesystems/proc.txt index aae9dd1..457cebd 100644 --- a/Documentation/filesystems/proc.txt +++ b/Documentation/filesystems/proc.txt @@ -197,12 +197,12 @@ contains details information about the process itself. Its fields are explained in Table 1-4. (for SMP CONFIG users) -For making accounting scalable, RSS related information are handled in -asynchronous manner and the vaule may not be very precise. To see a precise +For making accounting scalable, RSS related information are handled in an +asynchronous manner and the value may not be very precise. To see a precise snapshot of a moment, you can see /proc/pid/smaps file and scan page table. It's slow but very precise. -Table 1-2: Contents of the status files (as of 2.6.30-rc7) +Table 1-2: Contents of the status files (as of 3.20.0) .. Field Content Namefilename of the executable @@ -210,6 +210,7 @@ Table 1-2: Contents of the status files (as of 2.6.30-rc7) in an uninterruptible wait, Z is zombie, T is traced or stopped) Tgidthread group ID + NgidNUMA group ID (0 if none) Pid process id PPidprocess id of the parent process TracerPid PID of process tracing this process (0 if not) @@ -217,6 +218,10 @@ Table 1-2: Contents of the status files (as of 2.6.30-rc7) Gid Real, effective, saved set, and file system GIDs FDSize number of file descriptor slots currently allocated Groups supplementary group list + NStgid descendant namespace thread group ID hierarchy + NSpid descendant namespace process ID hierarchy + NSpgid descendant namespace process group ID hierarchy + NSsid descendant namespace session ID hierarchy VmPeak peak virtual memory size VmSize total program size VmLck locked memory size -- 2.1.0 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v10 1/2] /proc/PID/status: show all sets of pid according to ns
If some issues occurred inside a 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 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 Acked-by: Serge Hallyn serge.hal...@canonical.com Acked-by: Eric W. Biederman ebied...@xmission.com Tested-by: Serge Hallyn serge.hal...@canonical.com Tested-by: Nathan Scott nath...@redhat.com Signed-off-by: Chen Hanxiao chenhanx...@cn.fujitsu.com --- v10: remove trailing space of pid numbers \t%d - \t%d, rebased on 3.19-rc7 v9: rebased on 3.19-rc1 No change from v4-v8 v3: add another two fielsd: NSpgid and NSsid. v2: add two new fields: NStgid and NSpid. keep fields of Tgid and Pid unchanged for back compatibility. fs/proc/array.c | 16 1 file changed, 16 insertions(+) diff --git a/fs/proc/array.c b/fs/proc/array.c index bd117d0..f3e6d76 100644 --- a/fs/proc/array.c +++ b/fs/proc/array.c @@ -208,6 +208,22 @@ static inline void task_state(struct seq_file *m, struct pid_namespace *ns, from_kgid_munged(user_ns, GROUP_AT(group_info, g))); put_cred(cred); + seq_puts(m, \nNStgid:); + for (g = ns-level; g = pid-level; g++) + seq_printf(m, \t%d, + task_tgid_nr_ns(p, pid-numbers[g].ns)); + seq_puts(m, \nNSpid:); + for (g = ns-level; g = pid-level; g++) + seq_printf(m, \t%d, + task_pid_nr_ns(p, pid-numbers[g].ns)); + seq_puts(m, \nNSpgid:); + for (g = ns-level; g = pid-level; g++) + seq_printf(m, \t%d, + task_pgrp_nr_ns(p, pid-numbers[g].ns)); + seq_puts(m, \nNSsid:); + for (g = ns-level; g = pid-level; g++) + seq_printf(m, \t%d, + task_session_nr_ns(p, pid-numbers[g].ns)); seq_putc(m, '\n'); } -- 2.1.0 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [resend][PATCH v9 1/3] procfs: show hierarchy of pid namespace
> -Original Message-
> From: containers-boun...@lists.linux-foundation.org
> [mailto:containers-boun...@lists.linux-foundation.org] On Behalf Of Chen
> Hanxiao
> Sent: Tuesday, December 23, 2014 6:21 PM
> To: Eric W. Biederman; Serge Hallyn; Andrew Morton; Pavel Emelyanov
> Cc: Richard Weinberger; contain...@lists.linux-foundation.org;
> linux-kernel@vger.kernel.org; Oleg Nesterov; David Howells; Mateusz Guzik
> Subject: [resend][PATCH v9 1/3] procfs: show hierarchy of pid namespace
>
> 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 checkpoint/restore/migration
> c) bring trouble to pid translation between containers;
>
> This patch will show the hierarchy of pid namespace
> by pidns_hierarchy like:
>
>
>
Hi Eric, Pavel
Any comments?
Regards,
- Chen
> Ex:
> [root@localhost ~]#cat /proc/pidns_hierarchy
> 18060 1 1
> 18102 18060 2
> 1534 18102 3
> 1600 18102 3
> 1550 1 1
> *Note: numbers represent the pid 1 in different ns
>
> It shows the pid hierarchy below:
>
> init_pid_ns 1
> │
> ┌┐
> ns1 ns2
> ││
> 155018060
> │
> │
> ns3
> │
> 18102
> │
> ┌──┐
> ns4 ns5
> ││
> 1534 1600
>
> Every pid printed in pidns_hierarchy
> is the init pid of that pid ns level.
>
> Acked-by: Richard Weinberer
>
> Signed-off-by: Chen Hanxiao
> ---
> v9: fix codes be included if CONFIG_PID_NS=n
> v8: use max() from kernel.h
> fix some improper comments
> v7: change stype to be consistent with current interface like
>
> remove EXPERT dependent in Kconfig
> v6: fix a get_pid leak and do some cleanups;
> v5: collect pid by find_ge_pid;
> use local list inside nslist_proc_show;
> use get_pid, remove mutex lock.
> v4: simplify pid collection and some performance optimizamtion
> fix another race issue.
> v3: fix a race issue and memory leak issue
> v2: use a procfs text file instead of dirs under /proc
>
> fs/proc/Kconfig | 6 +
> fs/proc/Makefile | 1 +
> fs/proc/internal.h| 9 ++
> fs/proc/pidns_hierarchy.c | 280
> ++
> fs/proc/root.c| 1 +
> 5 files changed, 297 insertions(+)
> create mode 100644 fs/proc/pidns_hierarchy.c
>
> diff --git a/fs/proc/Kconfig b/fs/proc/Kconfig
> index 2183fcf..82dda55 100644
> --- a/fs/proc/Kconfig
> +++ b/fs/proc/Kconfig
> @@ -71,3 +71,9 @@ config PROC_PAGE_MONITOR
> /proc/pid/smaps, /proc/pid/clear_refs, /proc/pid/pagemap,
> /proc/kpagecount, and /proc/kpageflags. Disabling these
>interfaces will reduce the size of the kernel by approximately 4kb.
> +
> +config PROC_PID_HIERARCHY
> + bool "Enable /proc/pidns_hierarchy support"
> + depends on PROC_FS
> + help
> + Show pid namespace hierarchy information
> diff --git a/fs/proc/Makefile b/fs/proc/Makefile
> index 7151ea4..33e384b 100644
> --- a/fs/proc/Makefile
> +++ b/fs/proc/Makefile
> @@ -30,3 +30,4 @@ proc-$(CONFIG_PROC_KCORE) += kcore.o
> proc-$(CONFIG_PROC_VMCORE) += vmcore.o
> proc-$(CONFIG_PRINTK)+= kmsg.o
> proc-$(CONFIG_PROC_PAGE_MONITOR) += page.o
> +proc-$(CONFIG_PROC_PID_HIERARCHY)+= pidns_hierarchy.o
> diff --git a/fs/proc/internal.h b/fs/proc/internal.h
> index 6fcdba5..18e0773 100644
> --- a/fs/proc/internal.h
> +++ b/fs/proc/internal.h
> @@ -280,6 +280,15 @@ struct proc_maps_private {
> #endif
> };
>
> +/*
> + * pidns_hierarchy.c
> + */
> +#ifdef CONFIG_PROC_PID_HIERARCHY
> + extern void proc_pidns_hierarchy_init(void);
> +#else
> + static inline void proc_pidns_hierarchy_init(void) {}
> +#endif
> +
> struct mm_struct *proc_mem_open(struct inode *inode, unsigned int mode);
>
> extern const struct file_operations proc_pid_maps_operations;
> diff --git a/fs/proc/pidns_hierarchy.c b/fs/proc/pidns_hierarchy.c
> new file mode 100644
> index 000..ab1c665
> --- /dev/null
> +++ b/fs/proc/pidns_hierarchy.c
> @@ -0,0 +1,280 @@
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
&g
RE: [resend][PATCH v9 1/3] procfs: show hierarchy of pid namespace
-Original Message-
From: containers-boun...@lists.linux-foundation.org
[mailto:containers-boun...@lists.linux-foundation.org] On Behalf Of Chen
Hanxiao
Sent: Tuesday, December 23, 2014 6:21 PM
To: Eric W. Biederman; Serge Hallyn; Andrew Morton; Pavel Emelyanov
Cc: Richard Weinberger; contain...@lists.linux-foundation.org;
linux-kernel@vger.kernel.org; Oleg Nesterov; David Howells; Mateusz Guzik
Subject: [resend][PATCH v9 1/3] procfs: show hierarchy of pid namespace
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 checkpoint/restore/migration
c) bring trouble to pid translation between containers;
This patch will show the hierarchy of pid namespace
by pidns_hierarchy like:
init_PID parent_of_init_PID relative PID level
Hi Eric, Pavel
Any comments?
Regards,
- Chen
Ex:
[root@localhost ~]#cat /proc/pidns_hierarchy
18060 1 1
18102 18060 2
1534 18102 3
1600 18102 3
1550 1 1
*Note: numbers represent the pid 1 in different ns
It shows the pid hierarchy below:
init_pid_ns 1
│
┌┐
ns1 ns2
││
155018060
│
│
ns3
│
18102
│
┌──┐
ns4 ns5
││
1534 1600
Every pid printed in pidns_hierarchy
is the init pid of that pid ns level.
Acked-by: Richard Weinberer rich...@nod.at
Signed-off-by: Chen Hanxiao chenhanx...@cn.fujitsu.com
---
v9: fix codes be included if CONFIG_PID_NS=n
v8: use max() from kernel.h
fix some improper comments
v7: change stype to be consistent with current interface like
init_PID parent_of_init_PID relative PID level
remove EXPERT dependent in Kconfig
v6: fix a get_pid leak and do some cleanups;
v5: collect pid by find_ge_pid;
use local list inside nslist_proc_show;
use get_pid, remove mutex lock.
v4: simplify pid collection and some performance optimizamtion
fix another race issue.
v3: fix a race issue and memory leak issue
v2: use a procfs text file instead of dirs under /proc
fs/proc/Kconfig | 6 +
fs/proc/Makefile | 1 +
fs/proc/internal.h| 9 ++
fs/proc/pidns_hierarchy.c | 280
++
fs/proc/root.c| 1 +
5 files changed, 297 insertions(+)
create mode 100644 fs/proc/pidns_hierarchy.c
diff --git a/fs/proc/Kconfig b/fs/proc/Kconfig
index 2183fcf..82dda55 100644
--- a/fs/proc/Kconfig
+++ b/fs/proc/Kconfig
@@ -71,3 +71,9 @@ config PROC_PAGE_MONITOR
/proc/pid/smaps, /proc/pid/clear_refs, /proc/pid/pagemap,
/proc/kpagecount, and /proc/kpageflags. Disabling these
interfaces will reduce the size of the kernel by approximately 4kb.
+
+config PROC_PID_HIERARCHY
+ bool Enable /proc/pidns_hierarchy support
+ depends on PROC_FS
+ help
+ Show pid namespace hierarchy information
diff --git a/fs/proc/Makefile b/fs/proc/Makefile
index 7151ea4..33e384b 100644
--- a/fs/proc/Makefile
+++ b/fs/proc/Makefile
@@ -30,3 +30,4 @@ proc-$(CONFIG_PROC_KCORE) += kcore.o
proc-$(CONFIG_PROC_VMCORE) += vmcore.o
proc-$(CONFIG_PRINTK)+= kmsg.o
proc-$(CONFIG_PROC_PAGE_MONITOR) += page.o
+proc-$(CONFIG_PROC_PID_HIERARCHY)+= pidns_hierarchy.o
diff --git a/fs/proc/internal.h b/fs/proc/internal.h
index 6fcdba5..18e0773 100644
--- a/fs/proc/internal.h
+++ b/fs/proc/internal.h
@@ -280,6 +280,15 @@ struct proc_maps_private {
#endif
};
+/*
+ * pidns_hierarchy.c
+ */
+#ifdef CONFIG_PROC_PID_HIERARCHY
+ extern void proc_pidns_hierarchy_init(void);
+#else
+ static inline void proc_pidns_hierarchy_init(void) {}
+#endif
+
struct mm_struct *proc_mem_open(struct inode *inode, unsigned int mode);
extern const struct file_operations proc_pid_maps_operations;
diff --git a/fs/proc/pidns_hierarchy.c b/fs/proc/pidns_hierarchy.c
new file mode 100644
index 000..ab1c665
--- /dev/null
+++ b/fs/proc/pidns_hierarchy.c
@@ -0,0 +1,280 @@
+#include linux/init.h
+#include linux/errno.h
+#include linux/proc_fs.h
+#include linux/module.h
+#include linux/list.h
+#include linux/slab.h
+#include linux/pid_namespace.h
+#include linux/seq_file.h
+#include linux/kernel.h
+
+/*
+ * /proc/pidns_hierarchy
+ *
+ * show the hierarchy of pid namespace as:
+ * init_PID parent_of_init_PID relative PID level
+ *
+ * init_PID: child reaper in ns
+ * parent_of_init_PID: init_PID's parent, child reaper too
+ * relative PID level: pid level relative
[resend][PATCH v9 1/3] procfs: show hierarchy of pid namespace
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 checkpoint/restore/migration
c) bring trouble to pid translation between containers;
This patch will show the hierarchy of pid namespace
by pidns_hierarchy like:
Ex:
[root@localhost ~]#cat /proc/pidns_hierarchy
18060 1 1
18102 18060 2
1534 18102 3
1600 18102 3
1550 1 1
*Note: numbers represent the pid 1 in different ns
It shows the pid hierarchy below:
init_pid_ns 1
│
┌┐
ns1 ns2
││
155018060
│
│
ns3
│
18102
│
┌──┐
ns4 ns5
││
1534 1600
Every pid printed in pidns_hierarchy
is the init pid of that pid ns level.
Acked-by: Richard Weinberer
Signed-off-by: Chen Hanxiao
---
v9: fix codes be included if CONFIG_PID_NS=n
v8: use max() from kernel.h
fix some improper comments
v7: change stype to be consistent with current interface like
remove EXPERT dependent in Kconfig
v6: fix a get_pid leak and do some cleanups;
v5: collect pid by find_ge_pid;
use local list inside nslist_proc_show;
use get_pid, remove mutex lock.
v4: simplify pid collection and some performance optimizamtion
fix another race issue.
v3: fix a race issue and memory leak issue
v2: use a procfs text file instead of dirs under /proc
fs/proc/Kconfig | 6 +
fs/proc/Makefile | 1 +
fs/proc/internal.h| 9 ++
fs/proc/pidns_hierarchy.c | 280 ++
fs/proc/root.c| 1 +
5 files changed, 297 insertions(+)
create mode 100644 fs/proc/pidns_hierarchy.c
diff --git a/fs/proc/Kconfig b/fs/proc/Kconfig
index 2183fcf..82dda55 100644
--- a/fs/proc/Kconfig
+++ b/fs/proc/Kconfig
@@ -71,3 +71,9 @@ config PROC_PAGE_MONITOR
/proc/pid/smaps, /proc/pid/clear_refs, /proc/pid/pagemap,
/proc/kpagecount, and /proc/kpageflags. Disabling these
interfaces will reduce the size of the kernel by approximately 4kb.
+
+config PROC_PID_HIERARCHY
+ bool "Enable /proc/pidns_hierarchy support"
+ depends on PROC_FS
+ help
+ Show pid namespace hierarchy information
diff --git a/fs/proc/Makefile b/fs/proc/Makefile
index 7151ea4..33e384b 100644
--- a/fs/proc/Makefile
+++ b/fs/proc/Makefile
@@ -30,3 +30,4 @@ proc-$(CONFIG_PROC_KCORE) += kcore.o
proc-$(CONFIG_PROC_VMCORE) += vmcore.o
proc-$(CONFIG_PRINTK) += kmsg.o
proc-$(CONFIG_PROC_PAGE_MONITOR) += page.o
+proc-$(CONFIG_PROC_PID_HIERARCHY) += pidns_hierarchy.o
diff --git a/fs/proc/internal.h b/fs/proc/internal.h
index 6fcdba5..18e0773 100644
--- a/fs/proc/internal.h
+++ b/fs/proc/internal.h
@@ -280,6 +280,15 @@ struct proc_maps_private {
#endif
};
+/*
+ * pidns_hierarchy.c
+ */
+#ifdef CONFIG_PROC_PID_HIERARCHY
+ extern void proc_pidns_hierarchy_init(void);
+#else
+ static inline void proc_pidns_hierarchy_init(void) {}
+#endif
+
struct mm_struct *proc_mem_open(struct inode *inode, unsigned int mode);
extern const struct file_operations proc_pid_maps_operations;
diff --git a/fs/proc/pidns_hierarchy.c b/fs/proc/pidns_hierarchy.c
new file mode 100644
index 000..ab1c665
--- /dev/null
+++ b/fs/proc/pidns_hierarchy.c
@@ -0,0 +1,280 @@
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+/*
+ * /proc/pidns_hierarchy
+ *
+ * show the hierarchy of pid namespace as:
+ *
+ *
+ * init_PID: child reaper in ns
+ * parent_of_init_PID: init_PID's parent, child reaper too
+ * relative PID level: pid level relative to caller's ns
+ */
+
+#define NS_HIERARCHY "pidns_hierarchy"
+
+/* list for host pid collection */
+struct pidns_list {
+ struct list_head list;
+ struct pid *pid;
+ unsigned int level;
+};
+
+static void free_pidns_list(struct list_head *head)
+{
+ struct pidns_list *tmp, *pos;
+
+ list_for_each_entry_safe(pos, tmp, head, list) {
+ list_del(>list);
+ put_pid(pos->pid);
+ kfree(pos);
+ }
+}
+
+static int
+pidns_list_add(struct pid *pid, struct list_head *list_head,
+ int level)
+{
+ struct pidns_list *ent;
+
+ ent = kmalloc(sizeof(*ent), GFP_KERNEL);
+ if (!ent)
+ return -ENOMEM;
+
+ ent->pid = pid;
+ ent->level = level;
+ list_add_tail(>list, list_head);
+
+ return 0;
+}
+
+static int
+pidns_list_filter(struct list_head *pidns_pid_list,
+ struct list_head
[resend][PATCH v9 0/3] ns, procfs: pid conversion between ns and showing pidns hierarchy
This series will expose pid inside containers via procfs. Also show the hierarchy of pid namespcae. Then we could know how pid looks inside a container and their ns relationships. 1. helpful for nested container checkpoint/restore We could know whether two pids had relationship between each other. init_pid_ns 1 │ ┌┐ ns1 ns2 ││ 200 300 │ ns2 │ 400 #cat /proc/pidns_hierarchy 200 1 1 300 1 1 400 300 2 2. useful for pid translation from container Ex: init_pid_nsns1 ns2 t1 2 t2 `- 3 1 t3 `- 4 3 t4 `- 5 `- 51 t5 `- 6 `- 83 It could solve problems like: we see a pid 3 goes wrong in container's log, what is its pid on hosts: a) inside container: # readlink /proc/3/ns/pid pid:[4026532388] b) on host: We show it in the form of : # cat /proc/pidns_hierarchy 14918 1 1 16263 14918 2 16581 1 1 Then we could easily find /proc/16263/ns/pid->4026532388. On host, we knew that reported pid 3 is in level 2, and its parental pid ns is from pid 14918. c) on host, check child of 16263, grep it from status: NSpid: 16268 8 3 We knew that pid 16268 is pid 3 reported by container. v9: fix codes be inluded if CONFIG_PID_NS=n add docs to describe the usage of pidns_hierarchy procfs v8: fix some improper comments use max() from kernel.h v7: change pidns_hierarchy style to be consistent with current interface like: remove EXPERT dependent in Kconfig. v6: fix some get_pid leaks and do some cleanups. v5: collect pid by find_ge_pid; use local list inside nslist_proc_show; use get_pid, remove mutex lock. v4: simplify pid collection and some performance optimizamtion; fix another race issue. v3: fix a race issue and memory leak issue in pidns_hierarchy; add another two fielsd: NSpgid and NSsid. v2: use a procfs text file, replacing dirs under /proc for showing pidns hierarchy; add two new fields: NStgid and NSpid keep fields of Tgid and Pid unchanged for back compatibility. Chen Hanxiao (3): procfs: show hierarchy of pid namespace /proc/PID/status: show all sets of pid according to ns Documentation: add docs for /proc/pidns_hierarchy Documentation/namespaces/pidns-hierarchy.txt | 51 + fs/proc/Kconfig | 6 + fs/proc/Makefile | 1 + fs/proc/array.c | 16 ++ fs/proc/internal.h | 9 + fs/proc/pidns_hierarchy.c| 280 +++ fs/proc/root.c | 1 + 7 files changed, 364 insertions(+) create mode 100644 Documentation/namespaces/pidns-hierarchy.txt create mode 100644 fs/proc/pidns_hierarchy.c -- 1.9.3 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v9 3/3] Documentation: add docs for /proc/pidns_hierarchy
Signed-off-by: Chen Hanxiao --- Documentation/namespaces/pidns-hierarchy.txt | 51 1 file changed, 51 insertions(+) create mode 100644 Documentation/namespaces/pidns-hierarchy.txt diff --git a/Documentation/namespaces/pidns-hierarchy.txt b/Documentation/namespaces/pidns-hierarchy.txt new file mode 100644 index 000..feb92a9 --- /dev/null +++ b/Documentation/namespaces/pidns-hierarchy.txt @@ -0,0 +1,51 @@ +This document is about how to use pid namespace hierarchy procfs. + +We knew whether two pids living in the same pid namespace +by /proc/PID/ns/pid, but their relationships +between pids were unknown: +we couldn't tell that one pid was another one's parent/siblings... +But /proc/pidns_hierarchy could tell us the answer. + +/proc/pidns_hierarchy will show the hierarchy of pid namespace +in the form of: + + + +init_PID:child reaper in a pid namespace +parent_of_init_PID: init_PID's parent, child reaper too +relative PID level: pid level relative to caller's ns, + started from '1'. + +Here is a chart to describe the relationship between +some pids: + + init_pid_ns level 0 + | + 1 + | +┌┐ +ns1 ns2 level 1 +| | +155018060 + | + | + ns3 level 2 + | +18102 + | + ┌──┐ + ns4 ns5level 3 + | | +1534 1600 + +It will be showed by /proc/pidns_hierarchy as below: + +#cat /proc/pidns_hierarchy +18060 1 1 +18102 18060 2 +1534 18102 3 +1600 18102 3 +1550 1 1 + +Note: numbers in column 1 are pid numbers in current ns, +they represent the pid '1' in different ns -- 1.9.3 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[resend][PATCH v9 2/3] /proc/PID/status: show all sets of pid according to ns
If some issues occurred inside a 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 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 Acked-by: Serge Hallyn Tested-by: Serge Hallyn Signed-off-by: Chen Hanxiao --- v9: rebased on 3.19-rc1 No change from v4-v8 v3: add another two fielsd: NSpgid and NSsid. v2: add two new fields: NStgid and NSpid. keep fields of Tgid and Pid unchanged for back compatibility. fs/proc/array.c | 16 1 file changed, 16 insertions(+) diff --git a/fs/proc/array.c b/fs/proc/array.c index bd117d0..35205d4 100644 --- a/fs/proc/array.c +++ b/fs/proc/array.c @@ -208,6 +208,22 @@ static inline void task_state(struct seq_file *m, struct pid_namespace *ns, from_kgid_munged(user_ns, GROUP_AT(group_info, g))); put_cred(cred); + seq_puts(m, "\nNStgid:"); + for (g = ns->level; g <= pid->level; g++) + seq_printf(m, "\t%d ", + task_tgid_nr_ns(p, pid->numbers[g].ns)); + seq_puts(m, "\nNSpid:"); + for (g = ns->level; g <= pid->level; g++) + seq_printf(m, "\t%d ", + task_pid_nr_ns(p, pid->numbers[g].ns)); + seq_puts(m, "\nNSpgid:"); + for (g = ns->level; g <= pid->level; g++) + seq_printf(m, "\t%d ", + task_pgrp_nr_ns(p, pid->numbers[g].ns)); + seq_puts(m, "\nNSsid:"); + for (g = ns->level; g <= pid->level; g++) + seq_printf(m, "\t%d ", + task_session_nr_ns(p, pid->numbers[g].ns)); seq_putc(m, '\n'); } -- 1.9.3 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[resend][PATCH v9 2/3] /proc/PID/status: show all sets of pid according to ns
If some issues occurred inside a 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 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 Acked-by: Serge Hallyn serge.hal...@canonical.com Tested-by: Serge Hallyn serge.hal...@canonical.com Signed-off-by: Chen Hanxiao chenhanx...@cn.fujitsu.com --- v9: rebased on 3.19-rc1 No change from v4-v8 v3: add another two fielsd: NSpgid and NSsid. v2: add two new fields: NStgid and NSpid. keep fields of Tgid and Pid unchanged for back compatibility. fs/proc/array.c | 16 1 file changed, 16 insertions(+) diff --git a/fs/proc/array.c b/fs/proc/array.c index bd117d0..35205d4 100644 --- a/fs/proc/array.c +++ b/fs/proc/array.c @@ -208,6 +208,22 @@ static inline void task_state(struct seq_file *m, struct pid_namespace *ns, from_kgid_munged(user_ns, GROUP_AT(group_info, g))); put_cred(cred); + seq_puts(m, \nNStgid:); + for (g = ns-level; g = pid-level; g++) + seq_printf(m, \t%d , + task_tgid_nr_ns(p, pid-numbers[g].ns)); + seq_puts(m, \nNSpid:); + for (g = ns-level; g = pid-level; g++) + seq_printf(m, \t%d , + task_pid_nr_ns(p, pid-numbers[g].ns)); + seq_puts(m, \nNSpgid:); + for (g = ns-level; g = pid-level; g++) + seq_printf(m, \t%d , + task_pgrp_nr_ns(p, pid-numbers[g].ns)); + seq_puts(m, \nNSsid:); + for (g = ns-level; g = pid-level; g++) + seq_printf(m, \t%d , + task_session_nr_ns(p, pid-numbers[g].ns)); seq_putc(m, '\n'); } -- 1.9.3 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v9 3/3] Documentation: add docs for /proc/pidns_hierarchy
Signed-off-by: Chen Hanxiao chenhanx...@cn.fujitsu.com --- Documentation/namespaces/pidns-hierarchy.txt | 51 1 file changed, 51 insertions(+) create mode 100644 Documentation/namespaces/pidns-hierarchy.txt diff --git a/Documentation/namespaces/pidns-hierarchy.txt b/Documentation/namespaces/pidns-hierarchy.txt new file mode 100644 index 000..feb92a9 --- /dev/null +++ b/Documentation/namespaces/pidns-hierarchy.txt @@ -0,0 +1,51 @@ +This document is about how to use pid namespace hierarchy procfs. + +We knew whether two pids living in the same pid namespace +by /proc/PID/ns/pid, but their relationships +between pids were unknown: +we couldn't tell that one pid was another one's parent/siblings... +But /proc/pidns_hierarchy could tell us the answer. + +/proc/pidns_hierarchy will show the hierarchy of pid namespace +in the form of: + +init_PID parent_of_init_PID relative PID level + +init_PID:child reaper in a pid namespace +parent_of_init_PID: init_PID's parent, child reaper too +relative PID level: pid level relative to caller's ns, + started from '1'. + +Here is a chart to describe the relationship between +some pids: + + init_pid_ns level 0 + | + 1 + | +┌┐ +ns1 ns2 level 1 +| | +155018060 + | + | + ns3 level 2 + | +18102 + | + ┌──┐ + ns4 ns5level 3 + | | +1534 1600 + +It will be showed by /proc/pidns_hierarchy as below: + +#cat /proc/pidns_hierarchy +18060 1 1 +18102 18060 2 +1534 18102 3 +1600 18102 3 +1550 1 1 + +Note: numbers in column 1 are pid numbers in current ns, +they represent the pid '1' in different ns -- 1.9.3 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[resend][PATCH v9 1/3] procfs: show hierarchy of pid namespace
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 checkpoint/restore/migration
c) bring trouble to pid translation between containers;
This patch will show the hierarchy of pid namespace
by pidns_hierarchy like:
init_PID parent_of_init_PID relative PID level
Ex:
[root@localhost ~]#cat /proc/pidns_hierarchy
18060 1 1
18102 18060 2
1534 18102 3
1600 18102 3
1550 1 1
*Note: numbers represent the pid 1 in different ns
It shows the pid hierarchy below:
init_pid_ns 1
│
┌┐
ns1 ns2
││
155018060
│
│
ns3
│
18102
│
┌──┐
ns4 ns5
││
1534 1600
Every pid printed in pidns_hierarchy
is the init pid of that pid ns level.
Acked-by: Richard Weinberer rich...@nod.at
Signed-off-by: Chen Hanxiao chenhanx...@cn.fujitsu.com
---
v9: fix codes be included if CONFIG_PID_NS=n
v8: use max() from kernel.h
fix some improper comments
v7: change stype to be consistent with current interface like
init_PID parent_of_init_PID relative PID level
remove EXPERT dependent in Kconfig
v6: fix a get_pid leak and do some cleanups;
v5: collect pid by find_ge_pid;
use local list inside nslist_proc_show;
use get_pid, remove mutex lock.
v4: simplify pid collection and some performance optimizamtion
fix another race issue.
v3: fix a race issue and memory leak issue
v2: use a procfs text file instead of dirs under /proc
fs/proc/Kconfig | 6 +
fs/proc/Makefile | 1 +
fs/proc/internal.h| 9 ++
fs/proc/pidns_hierarchy.c | 280 ++
fs/proc/root.c| 1 +
5 files changed, 297 insertions(+)
create mode 100644 fs/proc/pidns_hierarchy.c
diff --git a/fs/proc/Kconfig b/fs/proc/Kconfig
index 2183fcf..82dda55 100644
--- a/fs/proc/Kconfig
+++ b/fs/proc/Kconfig
@@ -71,3 +71,9 @@ config PROC_PAGE_MONITOR
/proc/pid/smaps, /proc/pid/clear_refs, /proc/pid/pagemap,
/proc/kpagecount, and /proc/kpageflags. Disabling these
interfaces will reduce the size of the kernel by approximately 4kb.
+
+config PROC_PID_HIERARCHY
+ bool Enable /proc/pidns_hierarchy support
+ depends on PROC_FS
+ help
+ Show pid namespace hierarchy information
diff --git a/fs/proc/Makefile b/fs/proc/Makefile
index 7151ea4..33e384b 100644
--- a/fs/proc/Makefile
+++ b/fs/proc/Makefile
@@ -30,3 +30,4 @@ proc-$(CONFIG_PROC_KCORE) += kcore.o
proc-$(CONFIG_PROC_VMCORE) += vmcore.o
proc-$(CONFIG_PRINTK) += kmsg.o
proc-$(CONFIG_PROC_PAGE_MONITOR) += page.o
+proc-$(CONFIG_PROC_PID_HIERARCHY) += pidns_hierarchy.o
diff --git a/fs/proc/internal.h b/fs/proc/internal.h
index 6fcdba5..18e0773 100644
--- a/fs/proc/internal.h
+++ b/fs/proc/internal.h
@@ -280,6 +280,15 @@ struct proc_maps_private {
#endif
};
+/*
+ * pidns_hierarchy.c
+ */
+#ifdef CONFIG_PROC_PID_HIERARCHY
+ extern void proc_pidns_hierarchy_init(void);
+#else
+ static inline void proc_pidns_hierarchy_init(void) {}
+#endif
+
struct mm_struct *proc_mem_open(struct inode *inode, unsigned int mode);
extern const struct file_operations proc_pid_maps_operations;
diff --git a/fs/proc/pidns_hierarchy.c b/fs/proc/pidns_hierarchy.c
new file mode 100644
index 000..ab1c665
--- /dev/null
+++ b/fs/proc/pidns_hierarchy.c
@@ -0,0 +1,280 @@
+#include linux/init.h
+#include linux/errno.h
+#include linux/proc_fs.h
+#include linux/module.h
+#include linux/list.h
+#include linux/slab.h
+#include linux/pid_namespace.h
+#include linux/seq_file.h
+#include linux/kernel.h
+
+/*
+ * /proc/pidns_hierarchy
+ *
+ * show the hierarchy of pid namespace as:
+ * init_PID parent_of_init_PID relative PID level
+ *
+ * init_PID: child reaper in ns
+ * parent_of_init_PID: init_PID's parent, child reaper too
+ * relative PID level: pid level relative to caller's ns
+ */
+
+#define NS_HIERARCHY pidns_hierarchy
+
+/* list for host pid collection */
+struct pidns_list {
+ struct list_head list;
+ struct pid *pid;
+ unsigned int level;
+};
+
+static void free_pidns_list(struct list_head *head)
+{
+ struct pidns_list *tmp, *pos;
+
+ list_for_each_entry_safe(pos, tmp, head, list) {
+ list_del(pos-list);
+ put_pid(pos-pid);
+ kfree(pos);
+ }
+}
+
+static int
+pidns_list_add(struct pid *pid, struct list_head *list_head,
+ int level)
+{
+ struct pidns_list *ent;
+
+ ent = kmalloc(sizeof(*ent), GFP_KERNEL
[resend][PATCH v9 0/3] ns, procfs: pid conversion between ns and showing pidns hierarchy
This series will expose pid inside containers via procfs. Also show the hierarchy of pid namespcae. Then we could know how pid looks inside a container and their ns relationships. 1. helpful for nested container checkpoint/restore We could know whether two pids had relationship between each other. init_pid_ns 1 │ ┌┐ ns1 ns2 ││ 200 300 │ ns2 │ 400 #cat /proc/pidns_hierarchy 200 1 1 300 1 1 400 300 2 2. useful for pid translation from container Ex: init_pid_nsns1 ns2 t1 2 t2 `- 3 1 t3 `- 4 3 t4 `- 5 `- 51 t5 `- 6 `- 83 It could solve problems like: we see a pid 3 goes wrong in container's log, what is its pid on hosts: a) inside container: # readlink /proc/3/ns/pid pid:[4026532388] b) on host: We show it in the form of : init_PID parent_of_init_PID relative PID level # cat /proc/pidns_hierarchy 14918 1 1 16263 14918 2 16581 1 1 Then we could easily find /proc/16263/ns/pid-4026532388. On host, we knew that reported pid 3 is in level 2, and its parental pid ns is from pid 14918. c) on host, check child of 16263, grep it from status: NSpid: 16268 8 3 We knew that pid 16268 is pid 3 reported by container. v9: fix codes be inluded if CONFIG_PID_NS=n add docs to describe the usage of pidns_hierarchy procfs v8: fix some improper comments use max() from kernel.h v7: change pidns_hierarchy style to be consistent with current interface like: init_PID parent_of_init_PID relative PID level remove EXPERT dependent in Kconfig. v6: fix some get_pid leaks and do some cleanups. v5: collect pid by find_ge_pid; use local list inside nslist_proc_show; use get_pid, remove mutex lock. v4: simplify pid collection and some performance optimizamtion; fix another race issue. v3: fix a race issue and memory leak issue in pidns_hierarchy; add another two fielsd: NSpgid and NSsid. v2: use a procfs text file, replacing dirs under /proc for showing pidns hierarchy; add two new fields: NStgid and NSpid keep fields of Tgid and Pid unchanged for back compatibility. Chen Hanxiao (3): procfs: show hierarchy of pid namespace /proc/PID/status: show all sets of pid according to ns Documentation: add docs for /proc/pidns_hierarchy Documentation/namespaces/pidns-hierarchy.txt | 51 + fs/proc/Kconfig | 6 + fs/proc/Makefile | 1 + fs/proc/array.c | 16 ++ fs/proc/internal.h | 9 + fs/proc/pidns_hierarchy.c| 280 +++ fs/proc/root.c | 1 + 7 files changed, 364 insertions(+) create mode 100644 Documentation/namespaces/pidns-hierarchy.txt create mode 100644 fs/proc/pidns_hierarchy.c -- 1.9.3 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RESEND][PATCH] userns: use macro instead of magic number for max userns level
Use macro instead of magic number for max user namespace level. Acked-by: Serge E. Hallyn Signed-off-by: Chen Hanxiao --- kernel/user_namespace.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/kernel/user_namespace.c b/kernel/user_namespace.c index aa312b0..5435489 100644 --- a/kernel/user_namespace.c +++ b/kernel/user_namespace.c @@ -47,6 +47,8 @@ static void set_cred_user_ns(struct cred *cred, struct user_namespace *user_ns) cred->user_ns = user_ns; } +#define MAX_USER_NS_LEVEL 32 + /* * Create a new user namespace, deriving the creator from the user in the * passed credentials, and replacing that user with the new root user for the @@ -62,7 +64,7 @@ int create_user_ns(struct cred *new) kgid_t group = new->egid; int ret; - if (parent_ns->level > 32) + if (parent_ns->level > MAX_USER_NS_LEVEL) return -EUSERS; /* -- 1.9.3 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RESEND][PATCH] userns: use macro instead of magic number for max userns level
Use macro instead of magic number for max user namespace level. Acked-by: Serge E. Hallyn serge.hal...@ubuntu.com Signed-off-by: Chen Hanxiao chenhanx...@cn.fujitsu.com --- kernel/user_namespace.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/kernel/user_namespace.c b/kernel/user_namespace.c index aa312b0..5435489 100644 --- a/kernel/user_namespace.c +++ b/kernel/user_namespace.c @@ -47,6 +47,8 @@ static void set_cred_user_ns(struct cred *cred, struct user_namespace *user_ns) cred-user_ns = user_ns; } +#define MAX_USER_NS_LEVEL 32 + /* * Create a new user namespace, deriving the creator from the user in the * passed credentials, and replacing that user with the new root user for the @@ -62,7 +64,7 @@ int create_user_ns(struct cred *new) kgid_t group = new-egid; int ret; - if (parent_ns-level 32) + if (parent_ns-level MAX_USER_NS_LEVEL) return -EUSERS; /* -- 1.9.3 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [CFT] Can I get some Tested-By's on this series?
> -Original Message- > From: containers-boun...@lists.linux-foundation.org > [mailto:containers-boun...@lists.linux-foundation.org] On Behalf Of Eric W. > Biederman > Sent: Thursday, December 11, 2014 7:20 AM > To: Richard Weinberger > Cc: linux-man; Kees Cook; Linux API; Linux Containers; Serge Hallyn; Josh > Triplett; > stable; Andy Lutomirski; Kenton Varda; LSM; Michael Kerrisk-manpages; Casey > Schaufler; Andrew Morton; linux-kernel@vger.kernel.org > Subject: Re: [CFT] Can I get some Tested-By's on this series? > > Richard Weinberger writes: > > > Am 10.12.2014 um 23:48 schrieb Serge Hallyn: > >> Quoting Eric W. Biederman (ebied...@xmission.com): > >>> > >>> Will people please test these patches with their container project? > >>> > >>> These changes break container userspace (hopefully in a minimal way) if > >>> I could have that confirmed by testing I would really appreciate it. I > >>> really don't want to send out a bug fix that accidentally breaks > >>> userspace again. > >>> > >>> The only issue sort of under discussion is if there is a better name for > >>> /proc//setgroups, and the name of the file will not affect the > >>> functionality of the patchset. > >>> > >>> With the code reviewed and written in simple obviously correct, easily > >>> reviewable ways I am hoping/planning to send this to Linus ASAP. > >>> > >>> Eric > >> > >> Is there a git tree we can clone? > > > > I was about to ask that too. > > Hopefully I can tomorrow find some time for testing. > > git pull git.kernel.org:/pub/scm/linux/kernel/git/ebiederm/user-namespace.git > for-testing > > That holds my entire queue of fixes against 3.18-rc6 > Tested on Fedora20 with libvirt 1.2.11, works fine. Tested-by: Chen Hanxiao Thanks, - Chen
RE: [CFT] Can I get some Tested-By's on this series?
-Original Message- From: containers-boun...@lists.linux-foundation.org [mailto:containers-boun...@lists.linux-foundation.org] On Behalf Of Eric W. Biederman Sent: Thursday, December 11, 2014 7:20 AM To: Richard Weinberger Cc: linux-man; Kees Cook; Linux API; Linux Containers; Serge Hallyn; Josh Triplett; stable; Andy Lutomirski; Kenton Varda; LSM; Michael Kerrisk-manpages; Casey Schaufler; Andrew Morton; linux-kernel@vger.kernel.org Subject: Re: [CFT] Can I get some Tested-By's on this series? Richard Weinberger rich...@nod.at writes: Am 10.12.2014 um 23:48 schrieb Serge Hallyn: Quoting Eric W. Biederman (ebied...@xmission.com): Will people please test these patches with their container project? These changes break container userspace (hopefully in a minimal way) if I could have that confirmed by testing I would really appreciate it. I really don't want to send out a bug fix that accidentally breaks userspace again. The only issue sort of under discussion is if there is a better name for /proc/pid/setgroups, and the name of the file will not affect the functionality of the patchset. With the code reviewed and written in simple obviously correct, easily reviewable ways I am hoping/planning to send this to Linus ASAP. Eric Is there a git tree we can clone? I was about to ask that too. Hopefully I can tomorrow find some time for testing. git pull git.kernel.org:/pub/scm/linux/kernel/git/ebiederm/user-namespace.git for-testing That holds my entire queue of fixes against 3.18-rc6 Tested on Fedora20 with libvirt 1.2.11, works fine. Tested-by: Chen Hanxiao chenhanx...@cn.fujitsu.com Thanks, - Chen
RE: [PATCH v9 1/3] procfs: show hierarchy of pid namespace
> -Original Message- > From: containers-boun...@lists.linux-foundation.org > [mailto:containers-boun...@lists.linux-foundation.org] On Behalf Of Chen > Hanxiao > Sent: Monday, December 01, 2014 7:06 PM > To: Eric W. Biederman; Serge Hallyn; Oleg Nesterov; Richard Weinberger; Andrew > Morton > Cc: contain...@lists.linux-foundation.org; linux-kernel@vger.kernel.org; > Mateusz Guzik; David Howells > Subject: [PATCH v9 1/3] procfs: show hierarchy of pid namespace > > 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: > > > > Ex: > [root@localhost ~]#cat /proc/pidns_hierarchy > 18060 1 1 > 18102 18060 2 > 1534 18102 3 > 1600 18102 3 > 1550 1 1 > *Note: numbers represent the pid 1 in different ns > > It shows the pid hierarchy below: > > init_pid_ns 1 > │ > ┌┐ > ns1 ns2 > ││ > 155018060 > │ > │ > ns3 > │ > 18102 > │ > ┌──┐ > ns4 ns5 > ││ > 1534 1600 > > Every pid printed in pidns_hierarchy > is the init pid of that pid ns level. > > Acked-by: Richard Weinberer > > Signed-off-by: Chen Hanxiao > --- > v9: fix codes be included if CONFIG_PID_NS=n > v8: use max() from kernel.h > fix some improper comments > v7: change stype to be consistent with current interface like > > remove EXPERT dependent in Kconfig > v6: fix a get_pid leak and do some cleanups; > v5: collect pid by find_ge_pid; > use local list inside nslist_proc_show; > use get_pid, remove mutex lock. > v4: simplify pid collection and some performance optimizamtion > fix another race issue. > v3: fix a race issue and memory leak issue > v2: use a procfs text file instead of dirs under /proc > Hi, Any comments? Thanks, - Chen
RE: [PATCH v9 1/3] procfs: show hierarchy of pid namespace
-Original Message- From: containers-boun...@lists.linux-foundation.org [mailto:containers-boun...@lists.linux-foundation.org] On Behalf Of Chen Hanxiao Sent: Monday, December 01, 2014 7:06 PM To: Eric W. Biederman; Serge Hallyn; Oleg Nesterov; Richard Weinberger; Andrew Morton Cc: contain...@lists.linux-foundation.org; linux-kernel@vger.kernel.org; Mateusz Guzik; David Howells Subject: [PATCH v9 1/3] procfs: show hierarchy of pid namespace 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: init_PID parent_of_init_PID relative PID level Ex: [root@localhost ~]#cat /proc/pidns_hierarchy 18060 1 1 18102 18060 2 1534 18102 3 1600 18102 3 1550 1 1 *Note: numbers represent the pid 1 in different ns It shows the pid hierarchy below: init_pid_ns 1 │ ┌┐ ns1 ns2 ││ 155018060 │ │ ns3 │ 18102 │ ┌──┐ ns4 ns5 ││ 1534 1600 Every pid printed in pidns_hierarchy is the init pid of that pid ns level. Acked-by: Richard Weinberer rich...@nod.at Signed-off-by: Chen Hanxiao chenhanx...@cn.fujitsu.com --- v9: fix codes be included if CONFIG_PID_NS=n v8: use max() from kernel.h fix some improper comments v7: change stype to be consistent with current interface like init_PID parent_of_init_PID relative PID level remove EXPERT dependent in Kconfig v6: fix a get_pid leak and do some cleanups; v5: collect pid by find_ge_pid; use local list inside nslist_proc_show; use get_pid, remove mutex lock. v4: simplify pid collection and some performance optimizamtion fix another race issue. v3: fix a race issue and memory leak issue v2: use a procfs text file instead of dirs under /proc Hi, Any comments? Thanks, - Chen
[PATCH v9 2/3] /proc/PID/status: show all sets of pid according to ns
If some issues occurred inside a 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 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 Acked-by: Serge Hallyn Tested-by: Serge Hallyn Signed-off-by: Chen Hanxiao --- No change since v3 v3: add another two fielsd: NSpgid and NSsid. v2: add two new fields: NStgid and NSpid. keep fields of Tgid and Pid unchanged for back compatibility. fs/proc/array.c | 17 + 1 file changed, 17 insertions(+) diff --git a/fs/proc/array.c b/fs/proc/array.c index cd3653e..c30875d 100644 --- a/fs/proc/array.c +++ b/fs/proc/array.c @@ -193,6 +193,23 @@ static inline void task_state(struct seq_file *m, struct pid_namespace *ns, from_kgid_munged(user_ns, cred->egid), from_kgid_munged(user_ns, cred->sgid), from_kgid_munged(user_ns, cred->fsgid)); + seq_puts(m, "NStgid:"); + for (g = ns->level; g <= pid->level; g++) + seq_printf(m, "\t%d ", + task_tgid_nr_ns(p, pid->numbers[g].ns)); + seq_puts(m, "\nNSpid:"); + for (g = ns->level; g <= pid->level; g++) + seq_printf(m, "\t%d ", + task_pid_nr_ns(p, pid->numbers[g].ns)); + seq_puts(m, "\nNSpgid:"); + for (g = ns->level; g <= pid->level; g++) + seq_printf(m, "\t%d ", + task_pgrp_nr_ns(p, pid->numbers[g].ns)); + seq_puts(m, "\nNSsid:"); + for (g = ns->level; g <= pid->level; g++) + seq_printf(m, "\t%d ", + task_session_nr_ns(p, pid->numbers[g].ns)); + seq_putc(m, '\n'); task_lock(p); if (p->files) -- 1.9.3 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v9 3/3] Documentation: add docs for /proc/pidns_hierarchy
Signed-off-by: Chen Hanxiao --- Documentation/namespaces/pidns-hierarchy.txt | 51 1 file changed, 51 insertions(+) create mode 100644 Documentation/namespaces/pidns-hierarchy.txt diff --git a/Documentation/namespaces/pidns-hierarchy.txt b/Documentation/namespaces/pidns-hierarchy.txt new file mode 100644 index 000..1820ae6d --- /dev/null +++ b/Documentation/namespaces/pidns-hierarchy.txt @@ -0,0 +1,51 @@ +This document is about how to use pid namespace hierarchy procfs. + +We knew whether two pids living in the same pid namespace +by /proc/PID/ns/pid, but their relationships +between pids were unknown: +we couldn't tell that one pid was another one's parent/siblings... +But /proc/pidns_hierarchy could tell us the answer. + +/proc/pidns_hierarchy will show the hierarchy of pid namespace +in the form of: + + + +init_PID:child reaper in a pid namespace +parent_of_init_PID: init_PID's parent, child reaper too +relative PID level: pid level relative to caller's ns, + started from '1'. + +Here is a chart to describe the relationship between +some pids: + + init_pid_ns level 0 + | + 1 + | +┌┐ +ns1 ns2 level 1 +| | +155018060 + | + | + ns3 level 2 + | +18102 + | + ┌──┐ + ns4 ns5level 3 + | | +1534 1600 + +It will be showed by /proc/pidns_hierarchy as below: + +#cat /proc/pidns_hierarchy +18060 1 1 +18102 18060 2 +1534 18102 3 +1600 18102 3 +1550 1 1 + +Note: numbers in column 1 are pid numbers in current ns, +they represent the pid '1' in different ns -- 1.9.3 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v9 1/3] procfs: show hierarchy of pid namespace
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:
Ex:
[root@localhost ~]#cat /proc/pidns_hierarchy
18060 1 1
18102 18060 2
1534 18102 3
1600 18102 3
1550 1 1
*Note: numbers represent the pid 1 in different ns
It shows the pid hierarchy below:
init_pid_ns 1
│
┌┐
ns1 ns2
││
155018060
│
│
ns3
│
18102
│
┌──┐
ns4 ns5
││
1534 1600
Every pid printed in pidns_hierarchy
is the init pid of that pid ns level.
Acked-by: Richard Weinberer
Signed-off-by: Chen Hanxiao
---
v9: fix codes be included if CONFIG_PID_NS=n
v8: use max() from kernel.h
fix some improper comments
v7: change stype to be consistent with current interface like
remove EXPERT dependent in Kconfig
v6: fix a get_pid leak and do some cleanups;
v5: collect pid by find_ge_pid;
use local list inside nslist_proc_show;
use get_pid, remove mutex lock.
v4: simplify pid collection and some performance optimizamtion
fix another race issue.
v3: fix a race issue and memory leak issue
v2: use a procfs text file instead of dirs under /proc
fs/proc/Kconfig | 6 +
fs/proc/Makefile | 1 +
fs/proc/internal.h| 9 ++
fs/proc/pidns_hierarchy.c | 280 ++
fs/proc/root.c| 1 +
5 files changed, 297 insertions(+)
create mode 100644 fs/proc/pidns_hierarchy.c
diff --git a/fs/proc/Kconfig b/fs/proc/Kconfig
index 2183fcf..82dda55 100644
--- a/fs/proc/Kconfig
+++ b/fs/proc/Kconfig
@@ -71,3 +71,9 @@ config PROC_PAGE_MONITOR
/proc/pid/smaps, /proc/pid/clear_refs, /proc/pid/pagemap,
/proc/kpagecount, and /proc/kpageflags. Disabling these
interfaces will reduce the size of the kernel by approximately 4kb.
+
+config PROC_PID_HIERARCHY
+ bool "Enable /proc/pidns_hierarchy support"
+ depends on PROC_FS
+ help
+ Show pid namespace hierarchy information
diff --git a/fs/proc/Makefile b/fs/proc/Makefile
index 7151ea4..33e384b 100644
--- a/fs/proc/Makefile
+++ b/fs/proc/Makefile
@@ -30,3 +30,4 @@ proc-$(CONFIG_PROC_KCORE) += kcore.o
proc-$(CONFIG_PROC_VMCORE) += vmcore.o
proc-$(CONFIG_PRINTK) += kmsg.o
proc-$(CONFIG_PROC_PAGE_MONITOR) += page.o
+proc-$(CONFIG_PROC_PID_HIERARCHY) += pidns_hierarchy.o
diff --git a/fs/proc/internal.h b/fs/proc/internal.h
index aa7a0ee..276efd2 100644
--- a/fs/proc/internal.h
+++ b/fs/proc/internal.h
@@ -279,6 +279,15 @@ struct proc_maps_private {
#endif
};
+/*
+ * pidns_hierarchy.c
+ */
+#ifdef CONFIG_PROC_PID_HIERARCHY
+ extern void proc_pidns_hierarchy_init(void);
+#else
+ static inline void proc_pidns_hierarchy_init(void) {}
+#endif
+
struct mm_struct *proc_mem_open(struct inode *inode, unsigned int mode);
extern const struct file_operations proc_pid_maps_operations;
diff --git a/fs/proc/pidns_hierarchy.c b/fs/proc/pidns_hierarchy.c
new file mode 100644
index 000..d299b6d
--- /dev/null
+++ b/fs/proc/pidns_hierarchy.c
@@ -0,0 +1,280 @@
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+/*
+ * /proc/pidns_hierarchy
+ *
+ * show the hierarchy of pid namespace as:
+ *
+ *
+ * init_PID: child reaper in ns
+ * parent_of_init_PID: init_PID's parent, child reaper too
+ * relative PID level: pid level relative to caller's ns
+ */
+
+#define NS_HIERARCHY "pidns_hierarchy"
+
+/* list for host pid collection */
+struct pidns_list {
+ struct list_head list;
+ struct pid *pid;
+ unsigned int level;
+};
+
+static void free_pidns_list(struct list_head *head)
+{
+ struct pidns_list *tmp, *pos;
+
+ list_for_each_entry_safe(pos, tmp, head, list) {
+ list_del(>list);
+ put_pid(pos->pid);
+ kfree(pos);
+ }
+}
+
+static int
+pidns_list_add(struct pid *pid, struct list_head *list_head,
+ int level)
+{
+ struct pidns_list *ent;
+
+ ent = kmalloc(sizeof(*ent), GFP_KERNEL);
+ if (!ent)
+ return -ENOMEM;
+
+ ent->pid = pid;
+ ent->level = level;
+ list_add_tail(>list, list_head);
+
+ return 0;
+}
+
+static int
+pidns_list_filter(struct list_head *pidns_pid_list,
+ struct list_head *pidns_pid
[PATCH v9 0/3] ns, procfs: pid conversion between ns and showing pidns hierarchy
This series will expose pid inside containers via procfs. Also show the hierarchy of pid namespcae. Then we could know how pid looks inside a container and their ns relationships. 1. helpful for nested container check/restore >From /proc/PID/ns/pid, we could know whether two pid lived in the same ns. >From this patch, we could know whether two pid had relationship between each other. 2. used for pid translation from container Ex: init_pid_nsns1 ns2 t1 2 t2 `- 3 1 t3 `- 4 3 t4 `- 5 `- 51 t5 `- 6 `- 83 It could solve problems like: we see a pid 3 goes wrong in container's log, what is its pid on hosts: a) inside container: # readlink /proc/3/ns/pid pid:[4026532388] b) on host: We show it in the form of : # cat /proc/pidns_hierarchy 14918 1 1 16263 14918 2 16581 1 1 Then we could easily find /proc/16263/ns/pid->4026532388. On host, we knew that reported pid 3 is in level 2, and its parental pid ns is from pid 14918. c) on host, check child of 16263, grep it from status: NSpid: 16268 8 3 We knew that pid 16268 is pid 3 reported by container. v9: fix codes be inluded if CONFIG_PID_NS=n v8: fix some improper comments use max() from kernel.h v7: change stype to be consistent with current interface like remove EXPERT dependent in Kconfig v6: fix some get_pid leaks and do some cleanups v5: collect pid by find_ge_pid; use local list inside nslist_proc_show; use get_pid, remove mutex lock. v4: simplify pid collection and some performance optimizamtion fix another race issue. v3: fix a race issue and memory leak issue in pidns_hierarchy; add another two fielsd: NSpgid and NSsid. v2: use a procfs text file instead of dirs under /proc for showing pidns hierarchy; add two new fields: NStgid and NSpid keep fields of Tgid and Pid unchanged for back compatibility. Chen Hanxiao (3): procfs: show hierarchy of pid namespace /proc/PID/status: show all sets of pid according to ns Documentation: add docs for /proc/pidns_hierarchy Documentation/namespaces/pidns-hierarchy.txt | 51 + fs/proc/Kconfig | 6 + fs/proc/Makefile | 1 + fs/proc/array.c | 17 ++ fs/proc/internal.h | 9 + fs/proc/pidns_hierarchy.c| 280 +++ fs/proc/root.c | 1 + 7 files changed, 365 insertions(+) create mode 100644 Documentation/namespaces/pidns-hierarchy.txt create mode 100644 fs/proc/pidns_hierarchy.c -- 1.9.3 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v9 1/3] procfs: show hierarchy of pid namespace
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:
init_PID parent_of_init_PID relative PID level
Ex:
[root@localhost ~]#cat /proc/pidns_hierarchy
18060 1 1
18102 18060 2
1534 18102 3
1600 18102 3
1550 1 1
*Note: numbers represent the pid 1 in different ns
It shows the pid hierarchy below:
init_pid_ns 1
│
┌┐
ns1 ns2
││
155018060
│
│
ns3
│
18102
│
┌──┐
ns4 ns5
││
1534 1600
Every pid printed in pidns_hierarchy
is the init pid of that pid ns level.
Acked-by: Richard Weinberer rich...@nod.at
Signed-off-by: Chen Hanxiao chenhanx...@cn.fujitsu.com
---
v9: fix codes be included if CONFIG_PID_NS=n
v8: use max() from kernel.h
fix some improper comments
v7: change stype to be consistent with current interface like
init_PID parent_of_init_PID relative PID level
remove EXPERT dependent in Kconfig
v6: fix a get_pid leak and do some cleanups;
v5: collect pid by find_ge_pid;
use local list inside nslist_proc_show;
use get_pid, remove mutex lock.
v4: simplify pid collection and some performance optimizamtion
fix another race issue.
v3: fix a race issue and memory leak issue
v2: use a procfs text file instead of dirs under /proc
fs/proc/Kconfig | 6 +
fs/proc/Makefile | 1 +
fs/proc/internal.h| 9 ++
fs/proc/pidns_hierarchy.c | 280 ++
fs/proc/root.c| 1 +
5 files changed, 297 insertions(+)
create mode 100644 fs/proc/pidns_hierarchy.c
diff --git a/fs/proc/Kconfig b/fs/proc/Kconfig
index 2183fcf..82dda55 100644
--- a/fs/proc/Kconfig
+++ b/fs/proc/Kconfig
@@ -71,3 +71,9 @@ config PROC_PAGE_MONITOR
/proc/pid/smaps, /proc/pid/clear_refs, /proc/pid/pagemap,
/proc/kpagecount, and /proc/kpageflags. Disabling these
interfaces will reduce the size of the kernel by approximately 4kb.
+
+config PROC_PID_HIERARCHY
+ bool Enable /proc/pidns_hierarchy support
+ depends on PROC_FS
+ help
+ Show pid namespace hierarchy information
diff --git a/fs/proc/Makefile b/fs/proc/Makefile
index 7151ea4..33e384b 100644
--- a/fs/proc/Makefile
+++ b/fs/proc/Makefile
@@ -30,3 +30,4 @@ proc-$(CONFIG_PROC_KCORE) += kcore.o
proc-$(CONFIG_PROC_VMCORE) += vmcore.o
proc-$(CONFIG_PRINTK) += kmsg.o
proc-$(CONFIG_PROC_PAGE_MONITOR) += page.o
+proc-$(CONFIG_PROC_PID_HIERARCHY) += pidns_hierarchy.o
diff --git a/fs/proc/internal.h b/fs/proc/internal.h
index aa7a0ee..276efd2 100644
--- a/fs/proc/internal.h
+++ b/fs/proc/internal.h
@@ -279,6 +279,15 @@ struct proc_maps_private {
#endif
};
+/*
+ * pidns_hierarchy.c
+ */
+#ifdef CONFIG_PROC_PID_HIERARCHY
+ extern void proc_pidns_hierarchy_init(void);
+#else
+ static inline void proc_pidns_hierarchy_init(void) {}
+#endif
+
struct mm_struct *proc_mem_open(struct inode *inode, unsigned int mode);
extern const struct file_operations proc_pid_maps_operations;
diff --git a/fs/proc/pidns_hierarchy.c b/fs/proc/pidns_hierarchy.c
new file mode 100644
index 000..d299b6d
--- /dev/null
+++ b/fs/proc/pidns_hierarchy.c
@@ -0,0 +1,280 @@
+#include linux/init.h
+#include linux/errno.h
+#include linux/proc_fs.h
+#include linux/module.h
+#include linux/list.h
+#include linux/slab.h
+#include linux/pid_namespace.h
+#include linux/seq_file.h
+#include linux/kernel.h
+
+/*
+ * /proc/pidns_hierarchy
+ *
+ * show the hierarchy of pid namespace as:
+ * init_PID parent_of_init_PID relative PID level
+ *
+ * init_PID: child reaper in ns
+ * parent_of_init_PID: init_PID's parent, child reaper too
+ * relative PID level: pid level relative to caller's ns
+ */
+
+#define NS_HIERARCHY pidns_hierarchy
+
+/* list for host pid collection */
+struct pidns_list {
+ struct list_head list;
+ struct pid *pid;
+ unsigned int level;
+};
+
+static void free_pidns_list(struct list_head *head)
+{
+ struct pidns_list *tmp, *pos;
+
+ list_for_each_entry_safe(pos, tmp, head, list) {
+ list_del(pos-list);
+ put_pid(pos-pid);
+ kfree(pos);
+ }
+}
+
+static int
+pidns_list_add(struct pid *pid, struct list_head *list_head,
+ int level)
+{
+ struct pidns_list *ent;
+
+ ent = kmalloc(sizeof(*ent), GFP_KERNEL);
+ if (!ent
[PATCH v9 0/3] ns, procfs: pid conversion between ns and showing pidns hierarchy
This series will expose pid inside containers via procfs. Also show the hierarchy of pid namespcae. Then we could know how pid looks inside a container and their ns relationships. 1. helpful for nested container check/restore From /proc/PID/ns/pid, we could know whether two pid lived in the same ns. From this patch, we could know whether two pid had relationship between each other. 2. used for pid translation from container Ex: init_pid_nsns1 ns2 t1 2 t2 `- 3 1 t3 `- 4 3 t4 `- 5 `- 51 t5 `- 6 `- 83 It could solve problems like: we see a pid 3 goes wrong in container's log, what is its pid on hosts: a) inside container: # readlink /proc/3/ns/pid pid:[4026532388] b) on host: We show it in the form of : init_PID parent_of_init_PID relative PID level # cat /proc/pidns_hierarchy 14918 1 1 16263 14918 2 16581 1 1 Then we could easily find /proc/16263/ns/pid-4026532388. On host, we knew that reported pid 3 is in level 2, and its parental pid ns is from pid 14918. c) on host, check child of 16263, grep it from status: NSpid: 16268 8 3 We knew that pid 16268 is pid 3 reported by container. v9: fix codes be inluded if CONFIG_PID_NS=n v8: fix some improper comments use max() from kernel.h v7: change stype to be consistent with current interface like init_PID parent_of_init_PID relative PID level remove EXPERT dependent in Kconfig v6: fix some get_pid leaks and do some cleanups v5: collect pid by find_ge_pid; use local list inside nslist_proc_show; use get_pid, remove mutex lock. v4: simplify pid collection and some performance optimizamtion fix another race issue. v3: fix a race issue and memory leak issue in pidns_hierarchy; add another two fielsd: NSpgid and NSsid. v2: use a procfs text file instead of dirs under /proc for showing pidns hierarchy; add two new fields: NStgid and NSpid keep fields of Tgid and Pid unchanged for back compatibility. Chen Hanxiao (3): procfs: show hierarchy of pid namespace /proc/PID/status: show all sets of pid according to ns Documentation: add docs for /proc/pidns_hierarchy Documentation/namespaces/pidns-hierarchy.txt | 51 + fs/proc/Kconfig | 6 + fs/proc/Makefile | 1 + fs/proc/array.c | 17 ++ fs/proc/internal.h | 9 + fs/proc/pidns_hierarchy.c| 280 +++ fs/proc/root.c | 1 + 7 files changed, 365 insertions(+) create mode 100644 Documentation/namespaces/pidns-hierarchy.txt create mode 100644 fs/proc/pidns_hierarchy.c -- 1.9.3 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v9 3/3] Documentation: add docs for /proc/pidns_hierarchy
Signed-off-by: Chen Hanxiao chenhanx...@cn.fujitsu.com --- Documentation/namespaces/pidns-hierarchy.txt | 51 1 file changed, 51 insertions(+) create mode 100644 Documentation/namespaces/pidns-hierarchy.txt diff --git a/Documentation/namespaces/pidns-hierarchy.txt b/Documentation/namespaces/pidns-hierarchy.txt new file mode 100644 index 000..1820ae6d --- /dev/null +++ b/Documentation/namespaces/pidns-hierarchy.txt @@ -0,0 +1,51 @@ +This document is about how to use pid namespace hierarchy procfs. + +We knew whether two pids living in the same pid namespace +by /proc/PID/ns/pid, but their relationships +between pids were unknown: +we couldn't tell that one pid was another one's parent/siblings... +But /proc/pidns_hierarchy could tell us the answer. + +/proc/pidns_hierarchy will show the hierarchy of pid namespace +in the form of: + +init_PID parent_of_init_PID relative PID level + +init_PID:child reaper in a pid namespace +parent_of_init_PID: init_PID's parent, child reaper too +relative PID level: pid level relative to caller's ns, + started from '1'. + +Here is a chart to describe the relationship between +some pids: + + init_pid_ns level 0 + | + 1 + | +┌┐ +ns1 ns2 level 1 +| | +155018060 + | + | + ns3 level 2 + | +18102 + | + ┌──┐ + ns4 ns5level 3 + | | +1534 1600 + +It will be showed by /proc/pidns_hierarchy as below: + +#cat /proc/pidns_hierarchy +18060 1 1 +18102 18060 2 +1534 18102 3 +1600 18102 3 +1550 1 1 + +Note: numbers in column 1 are pid numbers in current ns, +they represent the pid '1' in different ns -- 1.9.3 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v9 2/3] /proc/PID/status: show all sets of pid according to ns
If some issues occurred inside a 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 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 Acked-by: Serge Hallyn serge.hal...@canonical.com Tested-by: Serge Hallyn serge.hal...@canonical.com Signed-off-by: Chen Hanxiao chenhanx...@cn.fujitsu.com --- No change since v3 v3: add another two fielsd: NSpgid and NSsid. v2: add two new fields: NStgid and NSpid. keep fields of Tgid and Pid unchanged for back compatibility. fs/proc/array.c | 17 + 1 file changed, 17 insertions(+) diff --git a/fs/proc/array.c b/fs/proc/array.c index cd3653e..c30875d 100644 --- a/fs/proc/array.c +++ b/fs/proc/array.c @@ -193,6 +193,23 @@ static inline void task_state(struct seq_file *m, struct pid_namespace *ns, from_kgid_munged(user_ns, cred-egid), from_kgid_munged(user_ns, cred-sgid), from_kgid_munged(user_ns, cred-fsgid)); + seq_puts(m, NStgid:); + for (g = ns-level; g = pid-level; g++) + seq_printf(m, \t%d , + task_tgid_nr_ns(p, pid-numbers[g].ns)); + seq_puts(m, \nNSpid:); + for (g = ns-level; g = pid-level; g++) + seq_printf(m, \t%d , + task_pid_nr_ns(p, pid-numbers[g].ns)); + seq_puts(m, \nNSpgid:); + for (g = ns-level; g = pid-level; g++) + seq_printf(m, \t%d , + task_pgrp_nr_ns(p, pid-numbers[g].ns)); + seq_puts(m, \nNSsid:); + for (g = ns-level; g = pid-level; g++) + seq_printf(m, \t%d , + task_session_nr_ns(p, pid-numbers[g].ns)); + seq_putc(m, '\n'); task_lock(p); if (p-files) -- 1.9.3 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH v8 1/2] procfs: show hierarchy of pid namespace
> -Original Message- > From: Andrew Morton [mailto:a...@linux-foundation.org] > Sent: Friday, November 21, 2014 6:21 AM > To: Richard Weinberger > Cc: Chen, Hanxiao/陈 晗霄; Eric W. Biederman; Serge Hallyn; Oleg Nesterov; > contain...@lists.linux-foundation.org; linux-kernel@vger.kernel.org; Mateusz > Guzik; David Howells > Subject: Re: [PATCH v8 1/2] procfs: show hierarchy of pid namespace > > On Thu, 20 Nov 2014 22:29:42 +0100 Richard Weinberger wrote: > > > > > > > Any comments? > > > > FWIW, Acked-by: Richard Weinberer > > > > The more challenging question is who will pickup this series? > > Eric? Andrew? > > I can monkey the patches but I'd very much like to hear Eric's comments. > > Also the CRIU people. How is CRIU presently reassembling these > relationships? > > Serge, what was your take on the usefulness/applicability of this work? > IOW, why the ack? Thanks for your attention and help. I'd very much like to hear Eric's comments on this patch too. Hi, Pavel, could you please provide some ideas from the CRIU's point of view? > > The patchset doesn't touch Documentation/. That will need to be fixed, > please. The new interfaces should be completely described in the > kernel documentation. I'll add a documentation patch soon. > > The new code appears to be included when CONFIG_PID_NS=n. Is there any > point in doing that? That code should not be included when CONFIG_PID_NS=n. Thanks, - Chen
RE: [PATCH v8 1/2] procfs: show hierarchy of pid namespace
-Original Message- From: Andrew Morton [mailto:a...@linux-foundation.org] Sent: Friday, November 21, 2014 6:21 AM To: Richard Weinberger Cc: Chen, Hanxiao/陈 晗霄; Eric W. Biederman; Serge Hallyn; Oleg Nesterov; contain...@lists.linux-foundation.org; linux-kernel@vger.kernel.org; Mateusz Guzik; David Howells Subject: Re: [PATCH v8 1/2] procfs: show hierarchy of pid namespace On Thu, 20 Nov 2014 22:29:42 +0100 Richard Weinberger rich...@nod.at wrote: Any comments? FWIW, Acked-by: Richard Weinberer rich...@nod.at The more challenging question is who will pickup this series? Eric? Andrew? I can monkey the patches but I'd very much like to hear Eric's comments. Also the CRIU people. How is CRIU presently reassembling these relationships? Serge, what was your take on the usefulness/applicability of this work? IOW, why the ack? Thanks for your attention and help. I'd very much like to hear Eric's comments on this patch too. Hi, Pavel, could you please provide some ideas from the CRIU's point of view? The patchset doesn't touch Documentation/. That will need to be fixed, please. The new interfaces should be completely described in the kernel documentation. I'll add a documentation patch soon. The new code appears to be included when CONFIG_PID_NS=n. Is there any point in doing that? That code should not be included when CONFIG_PID_NS=n. Thanks, - Chen
RE: [PATCH v8 1/2] procfs: show hierarchy of pid namespace
> -Original Message- > From: containers-boun...@lists.linux-foundation.org > [mailto:containers-boun...@lists.linux-foundation.org] On Behalf Of Chen > Hanxiao > Sent: Tuesday, November 18, 2014 5:30 PM > To: Eric W. Biederman; Serge Hallyn; Oleg Nesterov; Richard Weinberger > Cc: contain...@lists.linux-foundation.org; linux-kernel@vger.kernel.org; > Mateusz Guzik; David Howells > Subject: [PATCH v8 1/2] procfs: show hierarchy of pid namespace > > 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: > > > > Ex: > [root@localhost ~]#cat /proc/pidns_hierarchy > 18060 1 1 > 18102 18060 2 > 1534 18102 3 > 1600 18102 3 > 1550 1 1 > *Note: numbers represent the pid 1 in different ns > > It shows the pid hierarchy below: > > init_pid_ns 1 > │ > ┌┐ > ns1 ns2 > ││ > 155018060 > │ > │ > ns3 > │ > 18102 > │ > ┌──┐ > ns4 ns5 > ││ > 1534 1600 > > Every pid printed in pidns_hierarchy > is the init pid of that pid ns level. > > Signed-off-by: Chen Hanxiao > --- > v8: fix some improper comments > use max() from kernel.h > v7: change stype to be consistent with current interface like > > remove EXPERT dependent in Kconfig > v6: fix a get_pid leak and do some cleanups; > v5: collect pid by find_ge_pid; > use local list inside nslist_proc_show; > use get_pid, remove mutex lock. > v4: simplify pid collection and some performance optimizamtion > fix another race issue. > v3: fix a race issue and memory leak issue > v2: use a procfs text file instead of dirs under /proc > Hi, Any comments? Thanks, - Chen
RE: [PATCH v8 1/2] procfs: show hierarchy of pid namespace
-Original Message- From: containers-boun...@lists.linux-foundation.org [mailto:containers-boun...@lists.linux-foundation.org] On Behalf Of Chen Hanxiao Sent: Tuesday, November 18, 2014 5:30 PM To: Eric W. Biederman; Serge Hallyn; Oleg Nesterov; Richard Weinberger Cc: contain...@lists.linux-foundation.org; linux-kernel@vger.kernel.org; Mateusz Guzik; David Howells Subject: [PATCH v8 1/2] procfs: show hierarchy of pid namespace 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: init_PID parent_of_init_PID relative PID level Ex: [root@localhost ~]#cat /proc/pidns_hierarchy 18060 1 1 18102 18060 2 1534 18102 3 1600 18102 3 1550 1 1 *Note: numbers represent the pid 1 in different ns It shows the pid hierarchy below: init_pid_ns 1 │ ┌┐ ns1 ns2 ││ 155018060 │ │ ns3 │ 18102 │ ┌──┐ ns4 ns5 ││ 1534 1600 Every pid printed in pidns_hierarchy is the init pid of that pid ns level. Signed-off-by: Chen Hanxiao chenhanx...@cn.fujitsu.com --- v8: fix some improper comments use max() from kernel.h v7: change stype to be consistent with current interface like init_PID parent_of_init_PID relative PID level remove EXPERT dependent in Kconfig v6: fix a get_pid leak and do some cleanups; v5: collect pid by find_ge_pid; use local list inside nslist_proc_show; use get_pid, remove mutex lock. v4: simplify pid collection and some performance optimizamtion fix another race issue. v3: fix a race issue and memory leak issue v2: use a procfs text file instead of dirs under /proc Hi, Any comments? Thanks, - Chen
[PATCH v8 0/2] ns, procfs: pid conversion between ns and showing pidns hierarchy
This series will expose pid inside containers via procfs. Also show the hierarchy of pid namespcae. Then we could know how pid looks inside a container and their ns relationships. 1. helpful for nested container check/restore >From /proc/PID/ns/pid, we could know whether two pid lived in the same ns. >From this patch, we could know whether two pid had relationship between each other. 2. used for pid translation from container Ex: init_pid_nsns1 ns2 t1 2 t2 `- 3 1 t3 `- 4 3 t4 `- 5 `- 51 t5 `- 6 `- 83 It could solve problems like: we see a pid 3 goes wrong in container's log, what is its pid on hosts: a) inside container: # readlink /proc/3/ns/pid pid:[4026532388] b) on host: We show it in the form of : # cat /proc/pidns_hierarchy 14918 1 1 16263 14918 2 16581 1 1 Then we could easily find /proc/16263/ns/pid->4026532388. On host, we knew that reported pid 3 is in level 2, and its parental pid ns is from pid 14918. c) on host, check child of 16263, grep it from status: NSpid: 16268 8 3 We knew that pid 16268 is pid 3 reported by container. v8: fix some improper comments use max() from kernel.h v7: change stype to be consistent with current interface like remove EXPERT dependent in Kconfig v6: fix some get_pid leaks and do some cleanups v5: collect pid by find_ge_pid; use local list inside nslist_proc_show; use get_pid, remove mutex lock. v4: simplify pid collection and some performance optimizamtion fix another race issue. v3: fix a race issue and memory leak issue in pidns_hierarchy; add another two fielsd: NSpgid and NSsid. v2: use a procfs text file instead of dirs under /proc for showing pidns hierarchy; add two new fields: NStgid and NSpid keep fields of Tgid and Pid unchanged for back compatibility. Chen Hanxiao (2): procfs: show hierarchy of pid namespace /proc/PID/status: show all sets of pid according to ns fs/proc/Kconfig | 6 + fs/proc/Makefile | 1 + fs/proc/array.c | 17 +++ fs/proc/pidns_hierarchy.c | 280 ++ 4 files changed, 304 insertions(+) create mode 100644 fs/proc/pidns_hierarchy.c -- 1.9.3 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v8 1/2] procfs: show hierarchy of pid namespace
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:
Ex:
[root@localhost ~]#cat /proc/pidns_hierarchy
18060 1 1
18102 18060 2
1534 18102 3
1600 18102 3
1550 1 1
*Note: numbers represent the pid 1 in different ns
It shows the pid hierarchy below:
init_pid_ns 1
│
┌┐
ns1 ns2
││
155018060
│
│
ns3
│
18102
│
┌──┐
ns4 ns5
││
1534 1600
Every pid printed in pidns_hierarchy
is the init pid of that pid ns level.
Signed-off-by: Chen Hanxiao
---
v8: fix some improper comments
use max() from kernel.h
v7: change stype to be consistent with current interface like
remove EXPERT dependent in Kconfig
v6: fix a get_pid leak and do some cleanups;
v5: collect pid by find_ge_pid;
use local list inside nslist_proc_show;
use get_pid, remove mutex lock.
v4: simplify pid collection and some performance optimizamtion
fix another race issue.
v3: fix a race issue and memory leak issue
v2: use a procfs text file instead of dirs under /proc
fs/proc/Kconfig | 6 +
fs/proc/Makefile | 1 +
fs/proc/pidns_hierarchy.c | 280 ++
3 files changed, 287 insertions(+)
create mode 100644 fs/proc/pidns_hierarchy.c
diff --git a/fs/proc/Kconfig b/fs/proc/Kconfig
index 2183fcf..82dda55 100644
--- a/fs/proc/Kconfig
+++ b/fs/proc/Kconfig
@@ -71,3 +71,9 @@ config PROC_PAGE_MONITOR
/proc/pid/smaps, /proc/pid/clear_refs, /proc/pid/pagemap,
/proc/kpagecount, and /proc/kpageflags. Disabling these
interfaces will reduce the size of the kernel by approximately 4kb.
+
+config PROC_PID_HIERARCHY
+ bool "Enable /proc/pidns_hierarchy support"
+ depends on PROC_FS
+ help
+ Show pid namespace hierarchy information
diff --git a/fs/proc/Makefile b/fs/proc/Makefile
index 7151ea4..33e384b 100644
--- a/fs/proc/Makefile
+++ b/fs/proc/Makefile
@@ -30,3 +30,4 @@ proc-$(CONFIG_PROC_KCORE) += kcore.o
proc-$(CONFIG_PROC_VMCORE) += vmcore.o
proc-$(CONFIG_PRINTK) += kmsg.o
proc-$(CONFIG_PROC_PAGE_MONITOR) += page.o
+proc-$(CONFIG_PROC_PID_HIERARCHY) += pidns_hierarchy.o
diff --git a/fs/proc/pidns_hierarchy.c b/fs/proc/pidns_hierarchy.c
new file mode 100644
index 000..057d748
--- /dev/null
+++ b/fs/proc/pidns_hierarchy.c
@@ -0,0 +1,280 @@
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+/*
+ * /proc/pidns_hierarchy
+ *
+ * show the hierarchy of pid namespace as:
+ *
+ *
+ * init_PID: child reaper in ns
+ * parent_of_init_PID: init_PID's parent, child reaper too
+ * relative PID level: pid level relative to caller's ns
+ */
+
+#define NS_HIERARCHY "pidns_hierarchy"
+
+/* list for host pid collection */
+struct pidns_list {
+ struct list_head list;
+ struct pid *pid;
+ unsigned int level;
+};
+
+static void free_pidns_list(struct list_head *head)
+{
+ struct pidns_list *tmp, *pos;
+
+ list_for_each_entry_safe(pos, tmp, head, list) {
+ list_del(>list);
+ put_pid(pos->pid);
+ kfree(pos);
+ }
+}
+
+static int
+pidns_list_add(struct pid *pid, struct list_head *list_head,
+ int level)
+{
+ struct pidns_list *ent;
+
+ ent = kmalloc(sizeof(*ent), GFP_KERNEL);
+ if (!ent)
+ return -ENOMEM;
+
+ ent->pid = pid;
+ ent->level = level;
+ list_add_tail(>list, list_head);
+
+ return 0;
+}
+
+static int
+pidns_list_filter(struct list_head *pidns_pid_list,
+ struct list_head *pidns_pid_tree)
+{
+ struct pidns_list *pos, *pos_t;
+ struct pid_namespace *ns0, *ns1;
+ struct pid *pid0, *pid1;
+ int rc, flag = 0;
+
+ /*
+* screen pids with relationship
+* in pidns_pid_list, we may add pids like:
+* ns0 ns1 ns2
+* pid1->pid2->pid3
+* we should screen pid1, pid2 and keep pid3
+*/
+ list_for_each_entry(pos, pidns_pid_list, list) {
+ list_for_each_entry(pos_t, pidns_pid_list, list) {
+ flag = 0;
+ pid0 = pos->pid;
+ pid1 = pos_t->pid;
+ ns0 = pid0->numbers[p
[PATCH v8 2/2] /proc/PID/status: show all sets of pid according to ns
If some issues occurred inside a 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 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 Acked-by: Serge Hallyn Tested-by: Serge Hallyn Signed-off-by: Chen Hanxiao --- No change since v3 v3: add another two fielsd: NSpgid and NSsid. v2: add two new fields: NStgid and NSpid. keep fields of Tgid and Pid unchanged for back compatibility. fs/proc/array.c | 17 + 1 file changed, 17 insertions(+) diff --git a/fs/proc/array.c b/fs/proc/array.c index cd3653e..c30875d 100644 --- a/fs/proc/array.c +++ b/fs/proc/array.c @@ -193,6 +193,23 @@ static inline void task_state(struct seq_file *m, struct pid_namespace *ns, from_kgid_munged(user_ns, cred->egid), from_kgid_munged(user_ns, cred->sgid), from_kgid_munged(user_ns, cred->fsgid)); + seq_puts(m, "NStgid:"); + for (g = ns->level; g <= pid->level; g++) + seq_printf(m, "\t%d ", + task_tgid_nr_ns(p, pid->numbers[g].ns)); + seq_puts(m, "\nNSpid:"); + for (g = ns->level; g <= pid->level; g++) + seq_printf(m, "\t%d ", + task_pid_nr_ns(p, pid->numbers[g].ns)); + seq_puts(m, "\nNSpgid:"); + for (g = ns->level; g <= pid->level; g++) + seq_printf(m, "\t%d ", + task_pgrp_nr_ns(p, pid->numbers[g].ns)); + seq_puts(m, "\nNSsid:"); + for (g = ns->level; g <= pid->level; g++) + seq_printf(m, "\t%d ", + task_session_nr_ns(p, pid->numbers[g].ns)); + seq_putc(m, '\n'); task_lock(p); if (p->files) -- 1.9.3 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v8 2/2] /proc/PID/status: show all sets of pid according to ns
If some issues occurred inside a 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 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 Acked-by: Serge Hallyn serge.hal...@canonical.com Tested-by: Serge Hallyn serge.hal...@canonical.com Signed-off-by: Chen Hanxiao chenhanx...@cn.fujitsu.com --- No change since v3 v3: add another two fielsd: NSpgid and NSsid. v2: add two new fields: NStgid and NSpid. keep fields of Tgid and Pid unchanged for back compatibility. fs/proc/array.c | 17 + 1 file changed, 17 insertions(+) diff --git a/fs/proc/array.c b/fs/proc/array.c index cd3653e..c30875d 100644 --- a/fs/proc/array.c +++ b/fs/proc/array.c @@ -193,6 +193,23 @@ static inline void task_state(struct seq_file *m, struct pid_namespace *ns, from_kgid_munged(user_ns, cred-egid), from_kgid_munged(user_ns, cred-sgid), from_kgid_munged(user_ns, cred-fsgid)); + seq_puts(m, NStgid:); + for (g = ns-level; g = pid-level; g++) + seq_printf(m, \t%d , + task_tgid_nr_ns(p, pid-numbers[g].ns)); + seq_puts(m, \nNSpid:); + for (g = ns-level; g = pid-level; g++) + seq_printf(m, \t%d , + task_pid_nr_ns(p, pid-numbers[g].ns)); + seq_puts(m, \nNSpgid:); + for (g = ns-level; g = pid-level; g++) + seq_printf(m, \t%d , + task_pgrp_nr_ns(p, pid-numbers[g].ns)); + seq_puts(m, \nNSsid:); + for (g = ns-level; g = pid-level; g++) + seq_printf(m, \t%d , + task_session_nr_ns(p, pid-numbers[g].ns)); + seq_putc(m, '\n'); task_lock(p); if (p-files) -- 1.9.3 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v8 1/2] procfs: show hierarchy of pid namespace
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:
init_PID parent_of_init_PID relative PID level
Ex:
[root@localhost ~]#cat /proc/pidns_hierarchy
18060 1 1
18102 18060 2
1534 18102 3
1600 18102 3
1550 1 1
*Note: numbers represent the pid 1 in different ns
It shows the pid hierarchy below:
init_pid_ns 1
│
┌┐
ns1 ns2
││
155018060
│
│
ns3
│
18102
│
┌──┐
ns4 ns5
││
1534 1600
Every pid printed in pidns_hierarchy
is the init pid of that pid ns level.
Signed-off-by: Chen Hanxiao chenhanx...@cn.fujitsu.com
---
v8: fix some improper comments
use max() from kernel.h
v7: change stype to be consistent with current interface like
init_PID parent_of_init_PID relative PID level
remove EXPERT dependent in Kconfig
v6: fix a get_pid leak and do some cleanups;
v5: collect pid by find_ge_pid;
use local list inside nslist_proc_show;
use get_pid, remove mutex lock.
v4: simplify pid collection and some performance optimizamtion
fix another race issue.
v3: fix a race issue and memory leak issue
v2: use a procfs text file instead of dirs under /proc
fs/proc/Kconfig | 6 +
fs/proc/Makefile | 1 +
fs/proc/pidns_hierarchy.c | 280 ++
3 files changed, 287 insertions(+)
create mode 100644 fs/proc/pidns_hierarchy.c
diff --git a/fs/proc/Kconfig b/fs/proc/Kconfig
index 2183fcf..82dda55 100644
--- a/fs/proc/Kconfig
+++ b/fs/proc/Kconfig
@@ -71,3 +71,9 @@ config PROC_PAGE_MONITOR
/proc/pid/smaps, /proc/pid/clear_refs, /proc/pid/pagemap,
/proc/kpagecount, and /proc/kpageflags. Disabling these
interfaces will reduce the size of the kernel by approximately 4kb.
+
+config PROC_PID_HIERARCHY
+ bool Enable /proc/pidns_hierarchy support
+ depends on PROC_FS
+ help
+ Show pid namespace hierarchy information
diff --git a/fs/proc/Makefile b/fs/proc/Makefile
index 7151ea4..33e384b 100644
--- a/fs/proc/Makefile
+++ b/fs/proc/Makefile
@@ -30,3 +30,4 @@ proc-$(CONFIG_PROC_KCORE) += kcore.o
proc-$(CONFIG_PROC_VMCORE) += vmcore.o
proc-$(CONFIG_PRINTK) += kmsg.o
proc-$(CONFIG_PROC_PAGE_MONITOR) += page.o
+proc-$(CONFIG_PROC_PID_HIERARCHY) += pidns_hierarchy.o
diff --git a/fs/proc/pidns_hierarchy.c b/fs/proc/pidns_hierarchy.c
new file mode 100644
index 000..057d748
--- /dev/null
+++ b/fs/proc/pidns_hierarchy.c
@@ -0,0 +1,280 @@
+#include linux/init.h
+#include linux/errno.h
+#include linux/proc_fs.h
+#include linux/module.h
+#include linux/list.h
+#include linux/slab.h
+#include linux/pid_namespace.h
+#include linux/seq_file.h
+#include linux/kernel.h
+
+/*
+ * /proc/pidns_hierarchy
+ *
+ * show the hierarchy of pid namespace as:
+ * init_PID parent_of_init_PID relative PID level
+ *
+ * init_PID: child reaper in ns
+ * parent_of_init_PID: init_PID's parent, child reaper too
+ * relative PID level: pid level relative to caller's ns
+ */
+
+#define NS_HIERARCHY pidns_hierarchy
+
+/* list for host pid collection */
+struct pidns_list {
+ struct list_head list;
+ struct pid *pid;
+ unsigned int level;
+};
+
+static void free_pidns_list(struct list_head *head)
+{
+ struct pidns_list *tmp, *pos;
+
+ list_for_each_entry_safe(pos, tmp, head, list) {
+ list_del(pos-list);
+ put_pid(pos-pid);
+ kfree(pos);
+ }
+}
+
+static int
+pidns_list_add(struct pid *pid, struct list_head *list_head,
+ int level)
+{
+ struct pidns_list *ent;
+
+ ent = kmalloc(sizeof(*ent), GFP_KERNEL);
+ if (!ent)
+ return -ENOMEM;
+
+ ent-pid = pid;
+ ent-level = level;
+ list_add_tail(ent-list, list_head);
+
+ return 0;
+}
+
+static int
+pidns_list_filter(struct list_head *pidns_pid_list,
+ struct list_head *pidns_pid_tree)
+{
+ struct pidns_list *pos, *pos_t;
+ struct pid_namespace *ns0, *ns1;
+ struct pid *pid0, *pid1;
+ int rc, flag = 0;
+
+ /*
+* screen pids with relationship
+* in pidns_pid_list, we may add pids like:
+* ns0 ns1 ns2
+* pid1-pid2-pid3
+* we should screen pid1, pid2 and keep pid3
+*/
+ list_for_each_entry(pos, pidns_pid_list, list
[PATCH v8 0/2] ns, procfs: pid conversion between ns and showing pidns hierarchy
This series will expose pid inside containers via procfs. Also show the hierarchy of pid namespcae. Then we could know how pid looks inside a container and their ns relationships. 1. helpful for nested container check/restore From /proc/PID/ns/pid, we could know whether two pid lived in the same ns. From this patch, we could know whether two pid had relationship between each other. 2. used for pid translation from container Ex: init_pid_nsns1 ns2 t1 2 t2 `- 3 1 t3 `- 4 3 t4 `- 5 `- 51 t5 `- 6 `- 83 It could solve problems like: we see a pid 3 goes wrong in container's log, what is its pid on hosts: a) inside container: # readlink /proc/3/ns/pid pid:[4026532388] b) on host: We show it in the form of : init_PID parent_of_init_PID relative PID level # cat /proc/pidns_hierarchy 14918 1 1 16263 14918 2 16581 1 1 Then we could easily find /proc/16263/ns/pid-4026532388. On host, we knew that reported pid 3 is in level 2, and its parental pid ns is from pid 14918. c) on host, check child of 16263, grep it from status: NSpid: 16268 8 3 We knew that pid 16268 is pid 3 reported by container. v8: fix some improper comments use max() from kernel.h v7: change stype to be consistent with current interface like init_PID parent_of_init_PID relative PID level remove EXPERT dependent in Kconfig v6: fix some get_pid leaks and do some cleanups v5: collect pid by find_ge_pid; use local list inside nslist_proc_show; use get_pid, remove mutex lock. v4: simplify pid collection and some performance optimizamtion fix another race issue. v3: fix a race issue and memory leak issue in pidns_hierarchy; add another two fielsd: NSpgid and NSsid. v2: use a procfs text file instead of dirs under /proc for showing pidns hierarchy; add two new fields: NStgid and NSpid keep fields of Tgid and Pid unchanged for back compatibility. Chen Hanxiao (2): procfs: show hierarchy of pid namespace /proc/PID/status: show all sets of pid according to ns fs/proc/Kconfig | 6 + fs/proc/Makefile | 1 + fs/proc/array.c | 17 +++ fs/proc/pidns_hierarchy.c | 280 ++ 4 files changed, 304 insertions(+) create mode 100644 fs/proc/pidns_hierarchy.c -- 1.9.3 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[tip:sched/core] sched: Update comments about CLONE_NEWUTS and CLONE_NEWIPC
Commit-ID: f622b429dadf83c3cc2d70f57f407ad85684eb36 Gitweb: http://git.kernel.org/tip/f622b429dadf83c3cc2d70f57f407ad85684eb36 Author: Chen Hanxiao AuthorDate: Tue, 4 Nov 2014 16:51:22 +0800 Committer: Ingo Molnar CommitDate: Sun, 16 Nov 2014 10:58:53 +0100 sched: Update comments about CLONE_NEWUTS and CLONE_NEWIPC Remove question mark: s/New utsname group?/New utsname namespace Unified style for IPC: s/New ipcs/New ipc namespace Signed-off-by: Chen Hanxiao Acked-by: Serge E. Hallyn Signed-off-by: Peter Zijlstra (Intel) Cc: Jiri Kosina Cc: Linus Torvalds Cc: linux-...@vger.kernel.org Link: http://lkml.kernel.org/r/1415091082-15093-1-git-send-email-chenhanx...@cn.fujitsu.com Signed-off-by: Ingo Molnar --- include/uapi/linux/sched.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/include/uapi/linux/sched.h b/include/uapi/linux/sched.h index b932be9..cc89dde 100644 --- a/include/uapi/linux/sched.h +++ b/include/uapi/linux/sched.h @@ -23,8 +23,8 @@ #define CLONE_CHILD_SETTID 0x0100 /* set the TID in the child */ /* 0x0200 was previously the unused CLONE_STOPPED (Start in stopped state) and is now available for re-use. */ -#define CLONE_NEWUTS 0x0400 /* New utsname group? */ -#define CLONE_NEWIPC 0x0800 /* New ipcs */ +#define CLONE_NEWUTS 0x0400 /* New utsname namespace */ +#define CLONE_NEWIPC 0x0800 /* New ipc namespace */ #define CLONE_NEWUSER 0x1000 /* New user namespace */ #define CLONE_NEWPID 0x2000 /* New pid namespace */ #define CLONE_NEWNET 0x4000 /* New network namespace */ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[tip:sched/core] sched: Update comments about CLONE_NEWUTS and CLONE_NEWIPC
Commit-ID: f622b429dadf83c3cc2d70f57f407ad85684eb36 Gitweb: http://git.kernel.org/tip/f622b429dadf83c3cc2d70f57f407ad85684eb36 Author: Chen Hanxiao chenhanx...@cn.fujitsu.com AuthorDate: Tue, 4 Nov 2014 16:51:22 +0800 Committer: Ingo Molnar mi...@kernel.org CommitDate: Sun, 16 Nov 2014 10:58:53 +0100 sched: Update comments about CLONE_NEWUTS and CLONE_NEWIPC Remove question mark: s/New utsname group?/New utsname namespace Unified style for IPC: s/New ipcs/New ipc namespace Signed-off-by: Chen Hanxiao chenhanx...@cn.fujitsu.com Acked-by: Serge E. Hallyn serge.hal...@ubuntu.com Signed-off-by: Peter Zijlstra (Intel) pet...@infradead.org Cc: Jiri Kosina triv...@kernel.org Cc: Linus Torvalds torva...@linux-foundation.org Cc: linux-...@vger.kernel.org Link: http://lkml.kernel.org/r/1415091082-15093-1-git-send-email-chenhanx...@cn.fujitsu.com Signed-off-by: Ingo Molnar mi...@kernel.org --- include/uapi/linux/sched.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/include/uapi/linux/sched.h b/include/uapi/linux/sched.h index b932be9..cc89dde 100644 --- a/include/uapi/linux/sched.h +++ b/include/uapi/linux/sched.h @@ -23,8 +23,8 @@ #define CLONE_CHILD_SETTID 0x0100 /* set the TID in the child */ /* 0x0200 was previously the unused CLONE_STOPPED (Start in stopped state) and is now available for re-use. */ -#define CLONE_NEWUTS 0x0400 /* New utsname group? */ -#define CLONE_NEWIPC 0x0800 /* New ipcs */ +#define CLONE_NEWUTS 0x0400 /* New utsname namespace */ +#define CLONE_NEWIPC 0x0800 /* New ipc namespace */ #define CLONE_NEWUSER 0x1000 /* New user namespace */ #define CLONE_NEWPID 0x2000 /* New pid namespace */ #define CLONE_NEWNET 0x4000 /* New network namespace */ -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH v7 1/2] procfs: show hierarchy of pid namespace
> -Original Message-
> From: Richard Weinberger [mailto:rich...@nod.at]
> Sent: Wednesday, November 12, 2014 7:15 PM
> To: Chen, Hanxiao/陈 晗霄; Eric W. Biederman; Serge Hallyn; Oleg Nesterov
> Cc: contain...@lists.linux-foundation.org; linux-kernel@vger.kernel.org; David
> Howells; Richard Weinberger; Pavel Emelyanov; Vasiliy Kulikov; Mateusz Guzik
> Subject: Re: [PATCH v7 1/2] procfs: show hierarchy of pid namespace
>
> Am 12.11.2014 um 11:08 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:
> >
> >
> >
> > Ex:
> > [root@localhost ~]#cat /proc/pidns_hierarchy
> > 18060 1 1
> > 18102 18060 2
> > 1534 18102 3
> > 1600 18102 3
> > 1550 1 1
> > *Note: numbers represent the pid 1 in different ns
> >
[snip]
> > +
> > +#define NS_HIERARCHY "pidns_hierarchy"
> > +#define MAX(a, b) ((a) > (b) ? (a) : (b))
>
> Please use max() from kernel.h, there is no need to reinvent the wheel.
>
Thanks for your reminding.
> > +
> > +/* list for host pid collection */
> > +struct pidns_list {
> > + struct list_head list;
> > + struct pid *pid;
> > + int show_level;
>
> s/show_level/level, to keep it easy. :-)
Sure, also change the type to unsigned int
for making max() happy.
[snip]
> > +}
> > +
> > +/*
> > + * collect pids and stored in pidns_pid_list,
>
> s/stored/store
Oops...
>
> > + * then remove duplicated ones,
> > + * add the rest to pidns_pid_tree
> > + */
>
> This comment is a bit confusing.
>
> What about "proc_pidns_list_refresh - Finds all init pids, places them into
> pidns_pid_list
> and then stores the hirarchy into pidns_pid_tree."?
>
That's much more clear.
> Beside of my minor comments I like the patch. :-)
> Thanks a lot for doing this work!
>
Thanks for your kindly help. :)
- Chen
RE: [PATCH v7 1/2] procfs: show hierarchy of pid namespace
-Original Message-
From: Richard Weinberger [mailto:rich...@nod.at]
Sent: Wednesday, November 12, 2014 7:15 PM
To: Chen, Hanxiao/陈 晗霄; Eric W. Biederman; Serge Hallyn; Oleg Nesterov
Cc: contain...@lists.linux-foundation.org; linux-kernel@vger.kernel.org; David
Howells; Richard Weinberger; Pavel Emelyanov; Vasiliy Kulikov; Mateusz Guzik
Subject: Re: [PATCH v7 1/2] procfs: show hierarchy of pid namespace
Am 12.11.2014 um 11:08 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:
init_PID parent_of_init_PID relative PID level
Ex:
[root@localhost ~]#cat /proc/pidns_hierarchy
18060 1 1
18102 18060 2
1534 18102 3
1600 18102 3
1550 1 1
*Note: numbers represent the pid 1 in different ns
[snip]
+
+#define NS_HIERARCHY pidns_hierarchy
+#define MAX(a, b) ((a) (b) ? (a) : (b))
Please use max() from kernel.h, there is no need to reinvent the wheel.
Thanks for your reminding.
+
+/* list for host pid collection */
+struct pidns_list {
+ struct list_head list;
+ struct pid *pid;
+ int show_level;
s/show_level/level, to keep it easy. :-)
Sure, also change the type to unsigned int
for making max() happy.
[snip]
+}
+
+/*
+ * collect pids and stored in pidns_pid_list,
s/stored/store
Oops...
+ * then remove duplicated ones,
+ * add the rest to pidns_pid_tree
+ */
This comment is a bit confusing.
What about proc_pidns_list_refresh - Finds all init pids, places them into
pidns_pid_list
and then stores the hirarchy into pidns_pid_tree.?
That's much more clear.
Beside of my minor comments I like the patch. :-)
Thanks a lot for doing this work!
Thanks for your kindly help. :)
- Chen
[PATCH v7 1/2] procfs: show hierarchy of pid namespace
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:
Ex:
[root@localhost ~]#cat /proc/pidns_hierarchy
18060 1 1
18102 18060 2
1534 18102 3
1600 18102 3
1550 1 1
*Note: numbers represent the pid 1 in different ns
It shows the pid hierarchy below:
init_pid_ns 1
│
┌┐
ns1 ns2
││
155018060
│
│
ns3
│
18102
│
┌──┐
ns4 ns5
││
1534 1600
Every pid printed in pidns_hierarchy
is the init pid of that pid ns level.
Signed-off-by: Chen Hanxiao
---
v7: change stype to be consistent with current interface like
remove EXPERT dependent in Kconfig
v6: fix a get_pid leak and do some cleanups;
v5: collect pid by find_ge_pid;
use local list inside nslist_proc_show;
use get_pid, remove mutex lock.
v4: simplify pid collection and some performance optimizamtion
fix another race issue.
v3: fix a race issue and memory leak issue
v2: use a procfs text file instead of dirs under /proc
fs/proc/Kconfig | 6 +
fs/proc/Makefile | 1 +
fs/proc/pidns_hierarchy.c | 280 ++
3 files changed, 287 insertions(+)
create mode 100644 fs/proc/pidns_hierarchy.c
diff --git a/fs/proc/Kconfig b/fs/proc/Kconfig
index 2183fcf..82dda55 100644
--- a/fs/proc/Kconfig
+++ b/fs/proc/Kconfig
@@ -71,3 +71,9 @@ config PROC_PAGE_MONITOR
/proc/pid/smaps, /proc/pid/clear_refs, /proc/pid/pagemap,
/proc/kpagecount, and /proc/kpageflags. Disabling these
interfaces will reduce the size of the kernel by approximately 4kb.
+
+config PROC_PID_HIERARCHY
+ bool "Enable /proc/pidns_hierarchy support"
+ depends on PROC_FS
+ help
+ Show pid namespace hierarchy information
diff --git a/fs/proc/Makefile b/fs/proc/Makefile
index 7151ea4..33e384b 100644
--- a/fs/proc/Makefile
+++ b/fs/proc/Makefile
@@ -30,3 +30,4 @@ proc-$(CONFIG_PROC_KCORE) += kcore.o
proc-$(CONFIG_PROC_VMCORE) += vmcore.o
proc-$(CONFIG_PRINTK) += kmsg.o
proc-$(CONFIG_PROC_PAGE_MONITOR) += page.o
+proc-$(CONFIG_PROC_PID_HIERARCHY) += pidns_hierarchy.o
diff --git a/fs/proc/pidns_hierarchy.c b/fs/proc/pidns_hierarchy.c
new file mode 100644
index 000..4629bfd
--- /dev/null
+++ b/fs/proc/pidns_hierarchy.c
@@ -0,0 +1,280 @@
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+/*
+ * /proc/pidns_hierarchy
+ *
+ * show the hierarchy of pid namespace in:
+ *
+ *
+ * init_PID: child reaper in ns
+ * parent_of_init_PID: init_PID's parent, also child reaper
+ * relative PID level: pid level relative to caller's ns
+ */
+
+#define NS_HIERARCHY "pidns_hierarchy"
+#define MAX(a, b) ((a) > (b) ? (a) : (b))
+
+/* list for host pid collection */
+struct pidns_list {
+ struct list_head list;
+ struct pid *pid;
+ int show_level;
+};
+
+static void free_pidns_list(struct list_head *head)
+{
+ struct pidns_list *tmp, *pos;
+
+ list_for_each_entry_safe(pos, tmp, head, list) {
+ list_del(>list);
+ put_pid(pos->pid);
+ kfree(pos);
+ }
+}
+
+static int
+pidns_list_add(struct pid *pid, struct list_head *list_head,
+ int show_level)
+{
+ struct pidns_list *ent;
+
+ ent = kmalloc(sizeof(*ent), GFP_KERNEL);
+ if (!ent)
+ return -ENOMEM;
+
+ ent->pid = pid;
+ ent->show_level = show_level;
+ list_add_tail(>list, list_head);
+
+ return 0;
+}
+
+static int
+pidns_list_filter(struct list_head *pidns_pid_list,
+ struct list_head *pidns_pid_tree)
+{
+ struct pidns_list *pos, *pos_t;
+ struct pid_namespace *ns0, *ns1;
+ struct pid *pid0, *pid1;
+ int rc, flag = 0;
+
+ /*
+* screen pids with relationship
+* in pidns_pid_list, we may add pids like:
+* ns0 ns1 ns2
+* pid1->pid2->pid3
+* we should screen pid1, pid2 and keep pid3
+*/
+ list_for_each_entry(pos, pidns_pid_list, list) {
+ list_for_each_entry(pos_t, pidns_pid_list, list) {
+ flag = 0;
+ pid0 = pos->pid;
+ pid1 = pos_t->pid;
+ ns0 = pid0->numbers[pid0->lev
[PATCH v7 2/2] /proc/PID/status: show all sets of pid according to ns
If some issues occurred inside a 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 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 Acked-by: Serge Hallyn Tested-by: Serge Hallyn Signed-off-by: Chen Hanxiao --- No change since v3 v3: add another two fielsd: NSpgid and NSsid. v2: add two new fields: NStgid and NSpid. keep fields of Tgid and Pid unchanged for back compatibility. fs/proc/array.c | 17 + 1 file changed, 17 insertions(+) diff --git a/fs/proc/array.c b/fs/proc/array.c index cd3653e..c30875d 100644 --- a/fs/proc/array.c +++ b/fs/proc/array.c @@ -193,6 +193,23 @@ static inline void task_state(struct seq_file *m, struct pid_namespace *ns, from_kgid_munged(user_ns, cred->egid), from_kgid_munged(user_ns, cred->sgid), from_kgid_munged(user_ns, cred->fsgid)); + seq_puts(m, "NStgid:"); + for (g = ns->level; g <= pid->level; g++) + seq_printf(m, "\t%d ", + task_tgid_nr_ns(p, pid->numbers[g].ns)); + seq_puts(m, "\nNSpid:"); + for (g = ns->level; g <= pid->level; g++) + seq_printf(m, "\t%d ", + task_pid_nr_ns(p, pid->numbers[g].ns)); + seq_puts(m, "\nNSpgid:"); + for (g = ns->level; g <= pid->level; g++) + seq_printf(m, "\t%d ", + task_pgrp_nr_ns(p, pid->numbers[g].ns)); + seq_puts(m, "\nNSsid:"); + for (g = ns->level; g <= pid->level; g++) + seq_printf(m, "\t%d ", + task_session_nr_ns(p, pid->numbers[g].ns)); + seq_putc(m, '\n'); task_lock(p); if (p->files) -- 1.9.3 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v7 0/2] ns, procfs: pid conversion between ns and showing pidns hierarchy
This series will expose pid inside containers via procfs. Also show the hierarchy of pid namespcae. Then we could know how pid looks inside a container and their ns relationships. 1. helpful for nested container check/restore >From /proc/PID/ns/pid, we could know whether two pid lived in the same ns. >From this patch, we could know whether two pid had relationship between each other. 2. used for pid translation from container Ex: init_pid_nsns1 ns2 t1 2 t2 `- 3 1 t3 `- 4 3 t4 `- 5 `- 51 t5 `- 6 `- 83 It could solve problems like: we see a pid 3 goes wrong in container's log, what is its pid on hosts: a) inside container: # readlink /proc/3/ns/pid pid:[4026532388] b) on host: We show it in the form of : # cat /proc/pidns_hierarchy 14918 1 1 16263 14918 2 16581 1 1 Then we could easily find /proc/16263/ns/pid->4026532388. On host, we knew that reported pid 3 is in level 2, and its parental pid ns is from pid 14918. c) on host, check child of 16263, grep it from status: NSpid: 16268 8 3 We knew that pid 16268 is pid 3 reported by container. v7: change stype to be consistent with current interface like remove EXPERT dependent in Kconfig v6: fix some get_pid leaks and do some cleanups v5: collect pid by find_ge_pid; use local list inside nslist_proc_show; use get_pid, remove mutex lock. v4: simplify pid collection and some performance optimizamtion fix another race issue. v3: fix a race issue and memory leak issue in pidns_hierarchy; add another two fielsd: NSpgid and NSsid. v2: use a procfs text file instead of dirs under /proc for showing pidns hierarchy; add two new fields: NStgid and NSpid keep fields of Tgid and Pid unchanged for back compatibility. Chen Hanxiao (2): procfs: show hierarchy of pid namespace /proc/PID/status: show all sets of pid according to ns fs/proc/Kconfig | 6 + fs/proc/Makefile | 1 + fs/proc/array.c | 17 +++ fs/proc/pidns_hierarchy.c | 280 ++ 4 files changed, 304 insertions(+) create mode 100644 fs/proc/pidns_hierarchy.c -- 1.9.3 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v7 2/2] /proc/PID/status: show all sets of pid according to ns
If some issues occurred inside a 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 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 Acked-by: Serge Hallyn serge.hal...@canonical.com Tested-by: Serge Hallyn serge.hal...@canonical.com Signed-off-by: Chen Hanxiao chenhanx...@cn.fujitsu.com --- No change since v3 v3: add another two fielsd: NSpgid and NSsid. v2: add two new fields: NStgid and NSpid. keep fields of Tgid and Pid unchanged for back compatibility. fs/proc/array.c | 17 + 1 file changed, 17 insertions(+) diff --git a/fs/proc/array.c b/fs/proc/array.c index cd3653e..c30875d 100644 --- a/fs/proc/array.c +++ b/fs/proc/array.c @@ -193,6 +193,23 @@ static inline void task_state(struct seq_file *m, struct pid_namespace *ns, from_kgid_munged(user_ns, cred-egid), from_kgid_munged(user_ns, cred-sgid), from_kgid_munged(user_ns, cred-fsgid)); + seq_puts(m, NStgid:); + for (g = ns-level; g = pid-level; g++) + seq_printf(m, \t%d , + task_tgid_nr_ns(p, pid-numbers[g].ns)); + seq_puts(m, \nNSpid:); + for (g = ns-level; g = pid-level; g++) + seq_printf(m, \t%d , + task_pid_nr_ns(p, pid-numbers[g].ns)); + seq_puts(m, \nNSpgid:); + for (g = ns-level; g = pid-level; g++) + seq_printf(m, \t%d , + task_pgrp_nr_ns(p, pid-numbers[g].ns)); + seq_puts(m, \nNSsid:); + for (g = ns-level; g = pid-level; g++) + seq_printf(m, \t%d , + task_session_nr_ns(p, pid-numbers[g].ns)); + seq_putc(m, '\n'); task_lock(p); if (p-files) -- 1.9.3 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v7 0/2] ns, procfs: pid conversion between ns and showing pidns hierarchy
This series will expose pid inside containers via procfs. Also show the hierarchy of pid namespcae. Then we could know how pid looks inside a container and their ns relationships. 1. helpful for nested container check/restore From /proc/PID/ns/pid, we could know whether two pid lived in the same ns. From this patch, we could know whether two pid had relationship between each other. 2. used for pid translation from container Ex: init_pid_nsns1 ns2 t1 2 t2 `- 3 1 t3 `- 4 3 t4 `- 5 `- 51 t5 `- 6 `- 83 It could solve problems like: we see a pid 3 goes wrong in container's log, what is its pid on hosts: a) inside container: # readlink /proc/3/ns/pid pid:[4026532388] b) on host: We show it in the form of : init_PID parent_of_init_PID relative PID level # cat /proc/pidns_hierarchy 14918 1 1 16263 14918 2 16581 1 1 Then we could easily find /proc/16263/ns/pid-4026532388. On host, we knew that reported pid 3 is in level 2, and its parental pid ns is from pid 14918. c) on host, check child of 16263, grep it from status: NSpid: 16268 8 3 We knew that pid 16268 is pid 3 reported by container. v7: change stype to be consistent with current interface like init_PID parent_of_init_PID relative PID level remove EXPERT dependent in Kconfig v6: fix some get_pid leaks and do some cleanups v5: collect pid by find_ge_pid; use local list inside nslist_proc_show; use get_pid, remove mutex lock. v4: simplify pid collection and some performance optimizamtion fix another race issue. v3: fix a race issue and memory leak issue in pidns_hierarchy; add another two fielsd: NSpgid and NSsid. v2: use a procfs text file instead of dirs under /proc for showing pidns hierarchy; add two new fields: NStgid and NSpid keep fields of Tgid and Pid unchanged for back compatibility. Chen Hanxiao (2): procfs: show hierarchy of pid namespace /proc/PID/status: show all sets of pid according to ns fs/proc/Kconfig | 6 + fs/proc/Makefile | 1 + fs/proc/array.c | 17 +++ fs/proc/pidns_hierarchy.c | 280 ++ 4 files changed, 304 insertions(+) create mode 100644 fs/proc/pidns_hierarchy.c -- 1.9.3 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v7 1/2] procfs: show hierarchy of pid namespace
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:
init_PID parent_of_init_PID relative PID level
Ex:
[root@localhost ~]#cat /proc/pidns_hierarchy
18060 1 1
18102 18060 2
1534 18102 3
1600 18102 3
1550 1 1
*Note: numbers represent the pid 1 in different ns
It shows the pid hierarchy below:
init_pid_ns 1
│
┌┐
ns1 ns2
││
155018060
│
│
ns3
│
18102
│
┌──┐
ns4 ns5
││
1534 1600
Every pid printed in pidns_hierarchy
is the init pid of that pid ns level.
Signed-off-by: Chen Hanxiao chenhanx...@cn.fujitsu.com
---
v7: change stype to be consistent with current interface like
init_PID parent_of_init_PID relative PID level
remove EXPERT dependent in Kconfig
v6: fix a get_pid leak and do some cleanups;
v5: collect pid by find_ge_pid;
use local list inside nslist_proc_show;
use get_pid, remove mutex lock.
v4: simplify pid collection and some performance optimizamtion
fix another race issue.
v3: fix a race issue and memory leak issue
v2: use a procfs text file instead of dirs under /proc
fs/proc/Kconfig | 6 +
fs/proc/Makefile | 1 +
fs/proc/pidns_hierarchy.c | 280 ++
3 files changed, 287 insertions(+)
create mode 100644 fs/proc/pidns_hierarchy.c
diff --git a/fs/proc/Kconfig b/fs/proc/Kconfig
index 2183fcf..82dda55 100644
--- a/fs/proc/Kconfig
+++ b/fs/proc/Kconfig
@@ -71,3 +71,9 @@ config PROC_PAGE_MONITOR
/proc/pid/smaps, /proc/pid/clear_refs, /proc/pid/pagemap,
/proc/kpagecount, and /proc/kpageflags. Disabling these
interfaces will reduce the size of the kernel by approximately 4kb.
+
+config PROC_PID_HIERARCHY
+ bool Enable /proc/pidns_hierarchy support
+ depends on PROC_FS
+ help
+ Show pid namespace hierarchy information
diff --git a/fs/proc/Makefile b/fs/proc/Makefile
index 7151ea4..33e384b 100644
--- a/fs/proc/Makefile
+++ b/fs/proc/Makefile
@@ -30,3 +30,4 @@ proc-$(CONFIG_PROC_KCORE) += kcore.o
proc-$(CONFIG_PROC_VMCORE) += vmcore.o
proc-$(CONFIG_PRINTK) += kmsg.o
proc-$(CONFIG_PROC_PAGE_MONITOR) += page.o
+proc-$(CONFIG_PROC_PID_HIERARCHY) += pidns_hierarchy.o
diff --git a/fs/proc/pidns_hierarchy.c b/fs/proc/pidns_hierarchy.c
new file mode 100644
index 000..4629bfd
--- /dev/null
+++ b/fs/proc/pidns_hierarchy.c
@@ -0,0 +1,280 @@
+#include linux/init.h
+#include linux/errno.h
+#include linux/proc_fs.h
+#include linux/module.h
+#include linux/list.h
+#include linux/slab.h
+#include linux/pid_namespace.h
+#include linux/seq_file.h
+
+/*
+ * /proc/pidns_hierarchy
+ *
+ * show the hierarchy of pid namespace in:
+ * init_PID parent_of_init_PID relative PID level
+ *
+ * init_PID: child reaper in ns
+ * parent_of_init_PID: init_PID's parent, also child reaper
+ * relative PID level: pid level relative to caller's ns
+ */
+
+#define NS_HIERARCHY pidns_hierarchy
+#define MAX(a, b) ((a) (b) ? (a) : (b))
+
+/* list for host pid collection */
+struct pidns_list {
+ struct list_head list;
+ struct pid *pid;
+ int show_level;
+};
+
+static void free_pidns_list(struct list_head *head)
+{
+ struct pidns_list *tmp, *pos;
+
+ list_for_each_entry_safe(pos, tmp, head, list) {
+ list_del(pos-list);
+ put_pid(pos-pid);
+ kfree(pos);
+ }
+}
+
+static int
+pidns_list_add(struct pid *pid, struct list_head *list_head,
+ int show_level)
+{
+ struct pidns_list *ent;
+
+ ent = kmalloc(sizeof(*ent), GFP_KERNEL);
+ if (!ent)
+ return -ENOMEM;
+
+ ent-pid = pid;
+ ent-show_level = show_level;
+ list_add_tail(ent-list, list_head);
+
+ return 0;
+}
+
+static int
+pidns_list_filter(struct list_head *pidns_pid_list,
+ struct list_head *pidns_pid_tree)
+{
+ struct pidns_list *pos, *pos_t;
+ struct pid_namespace *ns0, *ns1;
+ struct pid *pid0, *pid1;
+ int rc, flag = 0;
+
+ /*
+* screen pids with relationship
+* in pidns_pid_list, we may add pids like:
+* ns0 ns1 ns2
+* pid1-pid2-pid3
+* we should screen pid1, pid2 and keep pid3
+*/
+ list_for_each_entry(pos, pidns_pid_list, list
RE: [PATCH 1/2v6] procfs: show hierarchy of pid namespace
> -Original Message-
> From: Mateusz Guzik [mailto:mgu...@redhat.com]
> Sent: Wednesday, November 05, 2014 7:54 PM
> To: Chen, Hanxiao/陈 晗霄
> Cc: Eric W. Biederman; Serge Hallyn; Oleg Nesterov;
> contain...@lists.linux-foundation.org; linux-kernel@vger.kernel.org; David
> Howells; Richard Weinberger; Pavel Emelyanov; Vasiliy Kulikov
> Subject: Re: [PATCH 1/2v6] procfs: show hierarchy of pid namespace
>
> On Wed, Nov 05, 2014 at 06:41:54PM +0800, Chen Hanxiao wrote:
> > +static void free_pidns_list(struct list_head *head)
> > +{
> > + struct pidns_list *tmp, *pos;
> > +
> > + list_for_each_entry_safe(pos, tmp, head, list) {
> > + list_del(>list);
>
> Any need for this one? stuff is freed anyway...
>
Yes, they're all freed.
But is that ok to leave a list full of freed stuffs..
[snip]
> > +
> > + if (flag == 0) {
> > + rcu_read_lock();
> > + get_pid(pos->pid);
> > + rcu_read_unlock();
>
> At this point you should have a valid reference for pid, so rcu should
> not matter.
>
Right.
>
> > + rc = pidns_list_add(pos->pid, pidns_pid_tree);
> > + if (rc) {
> > + put_pid(pos->pid);
> > + goto out;
> > +}
>
> '}' is misindented. Also 'out' is not a good label if it used solely for
> cleanup on error. 'out_err', 'fail' or something woud be better.
something wrong with my vimrc...
'out' is definitely not a good label.
I think 'cleanup' is a better one.
>
[snip]
> > +static int proc_pidns_list_refresh(struct pid_namespace *curr_ns,
> > + struct list_head *pidns_pid_list,
> > + struct list_head *pidns_pid_tree)
> > +{
> > + struct pid *pid;
> > + int new_nr, nr = 0;
> > + int rc;
> > +
> > + /* collect pids in current namespace */
> > + while (nr < PID_MAX_LIMIT) {
> > + rcu_read_lock();
> > + pid = find_ge_pid(nr, curr_ns);
> > + if (pid) {
> > + new_nr = pid_vnr(pid);
> > + if (!is_child_reaper(pid)) {
> > + nr = new_nr + 1;
> > + rcu_read_unlock();
> > + continue;
> > + }
> > + get_pid(pid);
> > + rcu_read_unlock();
> > + rc = pidns_list_add(pid, pidns_pid_list);
> > + if (rc) {
> > + put_pid(pid);
> > + goto out;
> > +}
> > + } else {
> > + rcu_read_unlock();
> > + break;
> > + }
> > + nr = new_nr + 1;
> > + }
> > +
>
> Would be beneficial to reorganize this loop. Handle shorter case (!pid)
> first.
OK.
>
> I consulted Dr. Grep and it told me about delayed_put_pid, so I guess
> pid itself is not going to be freed in the meantime, but this still
> seems fishy.
I found
call_rcu(>rcu, delayed_put_pid) in free_pid
Thanks,
- Chen
>
> > + /*
> > +* Only one pid found as the child reaper,
> > +* so current pid namespace do not have sub-namespace,
> > +* return 0 directly.
> > +*/
> > + if (list_is_singular(pidns_pid_list)) {
> > + rc = 0;
> > + goto out;
> > + }
> > +
> > + /*
> > +* screen duplicate pids from pidns_pid_list
> > +* and form a new list pidns_pid_tree.
> > +*/
> > + rc = pidns_list_filter(pidns_pid_list, pidns_pid_tree);
> > + if (rc)
> > + goto out;
> > +
> > + return 0;
> > +
> > +out:
> > + free_pidns_list(pidns_pid_list);
> > + return rc;
> > +}
> > +
> > +static int nslist_proc_show(struct seq_file *m, void *v)
> > +{
> > + struct pidns_list *pos;
> > + struct pid_namespace *ns, *curr_ns;
> > + struct pid *pid;
> > + char pid_buf[16];
> > + int i, rc;
> > +
> > + LIST_HEAD(pidns_pid_list);
> > + LIST_HEAD(pidns_pid_tree);
> > +
> > + curr_ns = task_active_pid_ns(current);
> > +
> > + rc = proc_pidns_list_refresh(curr_ns, _pid_list, _pid_tree);
> > + if (rc)
> > + return rc;
> > +
> > + /* print pid namespace's hierarchy */
> > + list_for_each_entry(pos, _pid_tree, list) {
> > + pid = pos->pi
RE: [PATCH 1/2v6] procfs: show hierarchy of pid namespace
-Original Message-
From: Mateusz Guzik [mailto:mgu...@redhat.com]
Sent: Wednesday, November 05, 2014 7:54 PM
To: Chen, Hanxiao/陈 晗霄
Cc: Eric W. Biederman; Serge Hallyn; Oleg Nesterov;
contain...@lists.linux-foundation.org; linux-kernel@vger.kernel.org; David
Howells; Richard Weinberger; Pavel Emelyanov; Vasiliy Kulikov
Subject: Re: [PATCH 1/2v6] procfs: show hierarchy of pid namespace
On Wed, Nov 05, 2014 at 06:41:54PM +0800, Chen Hanxiao wrote:
+static void free_pidns_list(struct list_head *head)
+{
+ struct pidns_list *tmp, *pos;
+
+ list_for_each_entry_safe(pos, tmp, head, list) {
+ list_del(pos-list);
Any need for this one? stuff is freed anyway...
Yes, they're all freed.
But is that ok to leave a list full of freed stuffs..
[snip]
+
+ if (flag == 0) {
+ rcu_read_lock();
+ get_pid(pos-pid);
+ rcu_read_unlock();
At this point you should have a valid reference for pid, so rcu should
not matter.
Right.
+ rc = pidns_list_add(pos-pid, pidns_pid_tree);
+ if (rc) {
+ put_pid(pos-pid);
+ goto out;
+}
'}' is misindented. Also 'out' is not a good label if it used solely for
cleanup on error. 'out_err', 'fail' or something woud be better.
something wrong with my vimrc...
'out' is definitely not a good label.
I think 'cleanup' is a better one.
[snip]
+static int proc_pidns_list_refresh(struct pid_namespace *curr_ns,
+ struct list_head *pidns_pid_list,
+ struct list_head *pidns_pid_tree)
+{
+ struct pid *pid;
+ int new_nr, nr = 0;
+ int rc;
+
+ /* collect pids in current namespace */
+ while (nr PID_MAX_LIMIT) {
+ rcu_read_lock();
+ pid = find_ge_pid(nr, curr_ns);
+ if (pid) {
+ new_nr = pid_vnr(pid);
+ if (!is_child_reaper(pid)) {
+ nr = new_nr + 1;
+ rcu_read_unlock();
+ continue;
+ }
+ get_pid(pid);
+ rcu_read_unlock();
+ rc = pidns_list_add(pid, pidns_pid_list);
+ if (rc) {
+ put_pid(pid);
+ goto out;
+}
+ } else {
+ rcu_read_unlock();
+ break;
+ }
+ nr = new_nr + 1;
+ }
+
Would be beneficial to reorganize this loop. Handle shorter case (!pid)
first.
OK.
I consulted Dr. Grep and it told me about delayed_put_pid, so I guess
pid itself is not going to be freed in the meantime, but this still
seems fishy.
I found
call_rcu(pid-rcu, delayed_put_pid) in free_pid
Thanks,
- Chen
+ /*
+* Only one pid found as the child reaper,
+* so current pid namespace do not have sub-namespace,
+* return 0 directly.
+*/
+ if (list_is_singular(pidns_pid_list)) {
+ rc = 0;
+ goto out;
+ }
+
+ /*
+* screen duplicate pids from pidns_pid_list
+* and form a new list pidns_pid_tree.
+*/
+ rc = pidns_list_filter(pidns_pid_list, pidns_pid_tree);
+ if (rc)
+ goto out;
+
+ return 0;
+
+out:
+ free_pidns_list(pidns_pid_list);
+ return rc;
+}
+
+static int nslist_proc_show(struct seq_file *m, void *v)
+{
+ struct pidns_list *pos;
+ struct pid_namespace *ns, *curr_ns;
+ struct pid *pid;
+ char pid_buf[16];
+ int i, rc;
+
+ LIST_HEAD(pidns_pid_list);
+ LIST_HEAD(pidns_pid_tree);
+
+ curr_ns = task_active_pid_ns(current);
+
+ rc = proc_pidns_list_refresh(curr_ns, pidns_pid_list, pidns_pid_tree);
+ if (rc)
+ return rc;
+
+ /* print pid namespace's hierarchy */
+ list_for_each_entry(pos, pidns_pid_tree, list) {
+ pid = pos-pid;
+ for (i = curr_ns-level + 1; i = pid-level; i++) {
+ ns = pid-numbers[i].ns;
+ /* show PID '1' in specific pid ns */
+ snprintf(pid_buf, 16, %u,
+ pid_vnr(find_pid_ns(1, ns)));
+ seq_printf(m, %s , pid_buf);
+ }
+
+ seq_putc(m, '\n');
+ }
+
+ free_pidns_list(pidns_pid_tree);
+
+ return 0;
+}
+
+static int nslist_proc_open(struct inode *inode, struct file *file)
+{
+ return single_open(file, nslist_proc_show, NULL);
+}
+
+static const struct file_operations proc_nspid_nslist_fops = {
+ .open = nslist_proc_open,
+ .read = seq_read,
+ .llseek = seq_lseek,
+ .release= single_release,
+};
+
+static int __init pidns_hierarchy_init(void
RE: [PATCH 1/2v6] procfs: show hierarchy of pid namespace
> -Original Message-
> From: Richard Weinberger [mailto:rich...@nod.at]
> Sent: Wednesday, November 05, 2014 8:52 PM
> To: Serge E. Hallyn
> Cc: Chen, Hanxiao/陈 晗霄; Eric W. Biederman; Serge Hallyn; Oleg Nesterov;
> contain...@lists.linux-foundation.org; linux-kernel@vger.kernel.org; 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 (rich...@nod.at):
> >> 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 . 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
N�Р骒r��yb�X�肚�v�^�)藓{.n�+�伐�{��赙zXФ�≤�}��财�z�:+v�����赙zZ+��+zf＂�h���~i���z� �wア�?�ㄨ��&�)撷f��^j谦y�m��@A�a囤�
0鹅h���i
[PATCH 2/2v6] /proc/PID/status: show all sets of pid according to ns
If some issues occurred inside a 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 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 Acked-by: Serge Hallyn Tested-by: Serge Hallyn Signed-off-by: Chen Hanxiao --- No change since v3 v3: add another two fielsd: NSpgid and NSsid. v2: add two new fields: NStgid and NSpid. keep fields of Tgid and Pid unchanged for back compatibility. fs/proc/array.c | 17 + 1 file changed, 17 insertions(+) diff --git a/fs/proc/array.c b/fs/proc/array.c index cd3653e..c30875d 100644 --- a/fs/proc/array.c +++ b/fs/proc/array.c @@ -193,6 +193,23 @@ static inline void task_state(struct seq_file *m, struct pid_namespace *ns, from_kgid_munged(user_ns, cred->egid), from_kgid_munged(user_ns, cred->sgid), from_kgid_munged(user_ns, cred->fsgid)); + seq_puts(m, "NStgid:"); + for (g = ns->level; g <= pid->level; g++) + seq_printf(m, "\t%d ", + task_tgid_nr_ns(p, pid->numbers[g].ns)); + seq_puts(m, "\nNSpid:"); + for (g = ns->level; g <= pid->level; g++) + seq_printf(m, "\t%d ", + task_pid_nr_ns(p, pid->numbers[g].ns)); + seq_puts(m, "\nNSpgid:"); + for (g = ns->level; g <= pid->level; g++) + seq_printf(m, "\t%d ", + task_pgrp_nr_ns(p, pid->numbers[g].ns)); + seq_puts(m, "\nNSsid:"); + for (g = ns->level; g <= pid->level; g++) + seq_printf(m, "\t%d ", + task_session_nr_ns(p, pid->numbers[g].ns)); + seq_putc(m, '\n'); task_lock(p); if (p->files) -- 1.9.3 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/2v6] ns, procfs: pid conversion between ns and showing pidns hierarchy
This series will expose pid inside containers via procfs. Also show the hierarchy of pid namespcae. Then we could know how pid looks inside a container and their ns relationships. 1. helpful for nested container check/restore >From /proc/PID/ns/pid, we could know whether two pid lived in the same ns. >From this patch, we could know whether two pid had relationship between each other. 2. used for pid translation from container Ex: init_pid_nsns1 ns2 t1 2 t2 `- 3 1 t3 `- 4 3 t4 `- 5 `- 51 t5 `- 6 `- 83 It could solve problems like: we see a pid 3 goes wrong in container's log, what is its pid on hosts: a) inside container: # readlink /proc/3/ns/pid pid:[4026532388] b) on host: # cat /proc/pidns_hierarchy 14918 16263 16581 Then we could easily find /proc/16263/ns/pid->4026532388. On host, we knew that reported pid 3 is in level 2, and its parental pid ns is from pid 14918. c) on host, check child of 16263, grep it from status: NSpid: 16268 8 3 We knew that pid 16268 is pid 3 reported by container. v6: fix some get_pid leaks and do some cleanups v5: collect pid by find_ge_pid; use local list inside nslist_proc_show; use get_pid, remove mutex lock. v4: simplify pid collection and some performance optimizamtion fix another race issue. v3: fix a race issue and memory leak issue in pidns_hierarchy; add another two fielsd: NSpgid and NSsid. v2: use a procfs text file instead of dirs under /proc for showing pidns hierarchy; add two new fields: NStgid and NSpid keep fields of Tgid and Pid unchanged for back compatibility. Chen Hanxiao (2): v5 procfs: show hierarchy of pid namespace /proc/PID/status: show all sets of pid according to ns fs/proc/Kconfig | 6 ++ fs/proc/Makefile | 1 + fs/proc/array.c | 17 fs/proc/pidns_hierarchy.c | 227 ++ 4 files changed, 251 insertions(+) create mode 100644 fs/proc/pidns_hierarchy.c -- 1.9.3 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/2v6] procfs: show hierarchy of pid namespace
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
*Note: numbers represent the pid 1 in different ns
It shows the pid hierarchy below:
init_pid_ns (not showed in /proc/pidns_hierarchy)
│
┌┐
ns1 ns2
││
155018060
│
│
ns3
│
18102
│
┌──┐
ns4 ns5
││
1534 1600
Every pid printed in pidns_hierarchy
is the init pid of that pid ns level.
Signed-off-by: Chen Hanxiao
---
v6: fix get_pid leaks and do some cleanups;
v5: collect pid by find_ge_pid;
use local list inside nslist_proc_show;
use get_pid, remove mutex lock.
v4: simplify pid collection and some performance optimizamtion
fix another race issue.
v3: fix a race issue and memory leak issue
v2: use a procfs text file instead of dirs under /proc
fs/proc/Kconfig | 6 ++
fs/proc/Makefile | 1 +
fs/proc/pidns_hierarchy.c | 227 ++
3 files changed, 234 insertions(+)
create mode 100644 fs/proc/pidns_hierarchy.c
diff --git a/fs/proc/Kconfig b/fs/proc/Kconfig
index 2183fcf..4bb111c 100644
--- a/fs/proc/Kconfig
+++ b/fs/proc/Kconfig
@@ -71,3 +71,9 @@ config PROC_PAGE_MONITOR
/proc/pid/smaps, /proc/pid/clear_refs, /proc/pid/pagemap,
/proc/kpagecount, and /proc/kpageflags. Disabling these
interfaces will reduce the size of the kernel by approximately 4kb.
+
+config PROC_PID_HIERARCHY
+ bool "Enable /proc/pidns_hierarchy support" if EXPERT
+ depends on PROC_FS
+ help
+ Show pid namespace hierarchy information
diff --git a/fs/proc/Makefile b/fs/proc/Makefile
index 7151ea4..33e384b 100644
--- a/fs/proc/Makefile
+++ b/fs/proc/Makefile
@@ -30,3 +30,4 @@ proc-$(CONFIG_PROC_KCORE) += kcore.o
proc-$(CONFIG_PROC_VMCORE) += vmcore.o
proc-$(CONFIG_PRINTK) += kmsg.o
proc-$(CONFIG_PROC_PAGE_MONITOR) += page.o
+proc-$(CONFIG_PROC_PID_HIERARCHY) += pidns_hierarchy.o
diff --git a/fs/proc/pidns_hierarchy.c b/fs/proc/pidns_hierarchy.c
new file mode 100644
index 000..aee359f
--- /dev/null
+++ b/fs/proc/pidns_hierarchy.c
@@ -0,0 +1,227 @@
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+/*
+ * /proc/pidns_hierarchy
+ *
+ * show the hierarchy of pid namespace
+ */
+
+#define NS_HIERARCHY "pidns_hierarchy"
+
+/* list for host pid collection */
+struct pidns_list {
+ struct list_head list;
+ struct pid *pid;
+};
+
+static void free_pidns_list(struct list_head *head)
+{
+ struct pidns_list *tmp, *pos;
+
+ list_for_each_entry_safe(pos, tmp, head, list) {
+ list_del(>list);
+ put_pid(pos->pid);
+ kfree(pos);
+ }
+}
+
+static int
+pidns_list_add(struct pid *pid, struct list_head *list_head)
+{
+ struct pidns_list *ent;
+
+ ent = kmalloc(sizeof(*ent), GFP_KERNEL);
+ if (!ent)
+ return -ENOMEM;
+
+ ent->pid = pid;
+ list_add_tail(>list, list_head);
+
+ return 0;
+}
+
+static int
+pidns_list_filter(struct list_head *pidns_pid_list,
+ struct list_head *pidns_pid_tree)
+{
+ struct pidns_list *pos, *pos_t;
+ struct pid_namespace *ns0, *ns1;
+ struct pid *pid0, *pid1;
+ int rc, flag = 0;
+
+ /*
+* screen pids with relationship
+* in pidns_pid_list, we may add pids like:
+* ns0 ns1 ns2
+* pid1->pid2->pid3
+* we should screen pid1, pid2 and keep pid3
+*/
+ list_for_each_entry(pos, pidns_pid_list, list) {
+ list_for_each_entry(pos_t, pidns_pid_list, list) {
+ flag = 0;
+ pid0 = pos->pid;
+ pid1 = pos_t->pid;
+ ns0 = pid0->numbers[pid0->level].ns;
+ ns1 = pid1->numbers[pid1->level].ns;
+ if (pos->pid->level < pos_t->pid->level)
+ for (; ns1 != NULL; ns1 = ns1->parent)
+ if (ns0 == ns1) {
+ flag = 1;
+ break;
+
[PATCH 1/2v6] procfs: show hierarchy of pid namespace
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
*Note: numbers represent the pid 1 in different ns
It shows the pid hierarchy below:
init_pid_ns (not showed in /proc/pidns_hierarchy)
│
┌┐
ns1 ns2
││
155018060
│
│
ns3
│
18102
│
┌──┐
ns4 ns5
││
1534 1600
Every pid printed in pidns_hierarchy
is the init pid of that pid ns level.
Signed-off-by: Chen Hanxiao chenhanx...@cn.fujitsu.com
---
v6: fix get_pid leaks and do some cleanups;
v5: collect pid by find_ge_pid;
use local list inside nslist_proc_show;
use get_pid, remove mutex lock.
v4: simplify pid collection and some performance optimizamtion
fix another race issue.
v3: fix a race issue and memory leak issue
v2: use a procfs text file instead of dirs under /proc
fs/proc/Kconfig | 6 ++
fs/proc/Makefile | 1 +
fs/proc/pidns_hierarchy.c | 227 ++
3 files changed, 234 insertions(+)
create mode 100644 fs/proc/pidns_hierarchy.c
diff --git a/fs/proc/Kconfig b/fs/proc/Kconfig
index 2183fcf..4bb111c 100644
--- a/fs/proc/Kconfig
+++ b/fs/proc/Kconfig
@@ -71,3 +71,9 @@ config PROC_PAGE_MONITOR
/proc/pid/smaps, /proc/pid/clear_refs, /proc/pid/pagemap,
/proc/kpagecount, and /proc/kpageflags. Disabling these
interfaces will reduce the size of the kernel by approximately 4kb.
+
+config PROC_PID_HIERARCHY
+ bool Enable /proc/pidns_hierarchy support if EXPERT
+ depends on PROC_FS
+ help
+ Show pid namespace hierarchy information
diff --git a/fs/proc/Makefile b/fs/proc/Makefile
index 7151ea4..33e384b 100644
--- a/fs/proc/Makefile
+++ b/fs/proc/Makefile
@@ -30,3 +30,4 @@ proc-$(CONFIG_PROC_KCORE) += kcore.o
proc-$(CONFIG_PROC_VMCORE) += vmcore.o
proc-$(CONFIG_PRINTK) += kmsg.o
proc-$(CONFIG_PROC_PAGE_MONITOR) += page.o
+proc-$(CONFIG_PROC_PID_HIERARCHY) += pidns_hierarchy.o
diff --git a/fs/proc/pidns_hierarchy.c b/fs/proc/pidns_hierarchy.c
new file mode 100644
index 000..aee359f
--- /dev/null
+++ b/fs/proc/pidns_hierarchy.c
@@ -0,0 +1,227 @@
+#include linux/init.h
+#include linux/errno.h
+#include linux/proc_fs.h
+#include linux/module.h
+#include linux/list.h
+#include linux/slab.h
+#include linux/pid_namespace.h
+#include linux/seq_file.h
+
+/*
+ * /proc/pidns_hierarchy
+ *
+ * show the hierarchy of pid namespace
+ */
+
+#define NS_HIERARCHY pidns_hierarchy
+
+/* list for host pid collection */
+struct pidns_list {
+ struct list_head list;
+ struct pid *pid;
+};
+
+static void free_pidns_list(struct list_head *head)
+{
+ struct pidns_list *tmp, *pos;
+
+ list_for_each_entry_safe(pos, tmp, head, list) {
+ list_del(pos-list);
+ put_pid(pos-pid);
+ kfree(pos);
+ }
+}
+
+static int
+pidns_list_add(struct pid *pid, struct list_head *list_head)
+{
+ struct pidns_list *ent;
+
+ ent = kmalloc(sizeof(*ent), GFP_KERNEL);
+ if (!ent)
+ return -ENOMEM;
+
+ ent-pid = pid;
+ list_add_tail(ent-list, list_head);
+
+ return 0;
+}
+
+static int
+pidns_list_filter(struct list_head *pidns_pid_list,
+ struct list_head *pidns_pid_tree)
+{
+ struct pidns_list *pos, *pos_t;
+ struct pid_namespace *ns0, *ns1;
+ struct pid *pid0, *pid1;
+ int rc, flag = 0;
+
+ /*
+* screen pids with relationship
+* in pidns_pid_list, we may add pids like:
+* ns0 ns1 ns2
+* pid1-pid2-pid3
+* we should screen pid1, pid2 and keep pid3
+*/
+ list_for_each_entry(pos, pidns_pid_list, list) {
+ list_for_each_entry(pos_t, pidns_pid_list, list) {
+ flag = 0;
+ pid0 = pos-pid;
+ pid1 = pos_t-pid;
+ ns0 = pid0-numbers[pid0-level].ns;
+ ns1 = pid1-numbers[pid1-level].ns;
+ if (pos-pid-level pos_t-pid-level)
+ for (; ns1 != NULL; ns1 = ns1-parent)
+ if (ns0 == ns1) {
+ flag = 1
[PATCH 0/2v6] ns, procfs: pid conversion between ns and showing pidns hierarchy
This series will expose pid inside containers via procfs. Also show the hierarchy of pid namespcae. Then we could know how pid looks inside a container and their ns relationships. 1. helpful for nested container check/restore From /proc/PID/ns/pid, we could know whether two pid lived in the same ns. From this patch, we could know whether two pid had relationship between each other. 2. used for pid translation from container Ex: init_pid_nsns1 ns2 t1 2 t2 `- 3 1 t3 `- 4 3 t4 `- 5 `- 51 t5 `- 6 `- 83 It could solve problems like: we see a pid 3 goes wrong in container's log, what is its pid on hosts: a) inside container: # readlink /proc/3/ns/pid pid:[4026532388] b) on host: # cat /proc/pidns_hierarchy 14918 16263 16581 Then we could easily find /proc/16263/ns/pid-4026532388. On host, we knew that reported pid 3 is in level 2, and its parental pid ns is from pid 14918. c) on host, check child of 16263, grep it from status: NSpid: 16268 8 3 We knew that pid 16268 is pid 3 reported by container. v6: fix some get_pid leaks and do some cleanups v5: collect pid by find_ge_pid; use local list inside nslist_proc_show; use get_pid, remove mutex lock. v4: simplify pid collection and some performance optimizamtion fix another race issue. v3: fix a race issue and memory leak issue in pidns_hierarchy; add another two fielsd: NSpgid and NSsid. v2: use a procfs text file instead of dirs under /proc for showing pidns hierarchy; add two new fields: NStgid and NSpid keep fields of Tgid and Pid unchanged for back compatibility. Chen Hanxiao (2): v5 procfs: show hierarchy of pid namespace /proc/PID/status: show all sets of pid according to ns fs/proc/Kconfig | 6 ++ fs/proc/Makefile | 1 + fs/proc/array.c | 17 fs/proc/pidns_hierarchy.c | 227 ++ 4 files changed, 251 insertions(+) create mode 100644 fs/proc/pidns_hierarchy.c -- 1.9.3 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/2v6] /proc/PID/status: show all sets of pid according to ns
If some issues occurred inside a 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 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 Acked-by: Serge Hallyn serge.hal...@canonical.com Tested-by: Serge Hallyn serge.hal...@canonical.com Signed-off-by: Chen Hanxiao chenhanx...@cn.fujitsu.com --- No change since v3 v3: add another two fielsd: NSpgid and NSsid. v2: add two new fields: NStgid and NSpid. keep fields of Tgid and Pid unchanged for back compatibility. fs/proc/array.c | 17 + 1 file changed, 17 insertions(+) diff --git a/fs/proc/array.c b/fs/proc/array.c index cd3653e..c30875d 100644 --- a/fs/proc/array.c +++ b/fs/proc/array.c @@ -193,6 +193,23 @@ static inline void task_state(struct seq_file *m, struct pid_namespace *ns, from_kgid_munged(user_ns, cred-egid), from_kgid_munged(user_ns, cred-sgid), from_kgid_munged(user_ns, cred-fsgid)); + seq_puts(m, NStgid:); + for (g = ns-level; g = pid-level; g++) + seq_printf(m, \t%d , + task_tgid_nr_ns(p, pid-numbers[g].ns)); + seq_puts(m, \nNSpid:); + for (g = ns-level; g = pid-level; g++) + seq_printf(m, \t%d , + task_pid_nr_ns(p, pid-numbers[g].ns)); + seq_puts(m, \nNSpgid:); + for (g = ns-level; g = pid-level; g++) + seq_printf(m, \t%d , + task_pgrp_nr_ns(p, pid-numbers[g].ns)); + seq_puts(m, \nNSsid:); + for (g = ns-level; g = pid-level; g++) + seq_printf(m, \t%d , + task_session_nr_ns(p, pid-numbers[g].ns)); + seq_putc(m, '\n'); task_lock(p); if (p-files) -- 1.9.3 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 1/2v6] procfs: show hierarchy of pid namespace
-Original Message-
From: Richard Weinberger [mailto:rich...@nod.at]
Sent: Wednesday, November 05, 2014 8:52 PM
To: Serge E. Hallyn
Cc: Chen, Hanxiao/陈 晗霄; Eric W. Biederman; Serge Hallyn; Oleg Nesterov;
contain...@lists.linux-foundation.org; linux-kernel@vger.kernel.org; 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 (rich...@nod.at):
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
N�Р骒r��yb�X�肚�v�^�)藓{.n�+�伐�{��赙zXФ�≤�}��财�z�j:+v�����赙zZ+��+zf＂�h���~i���z� �wア�?�ㄨ���)撷f��^j谦y�m��@A�a囤�
0鹅h���i
[PATCH] sched: updated comments of CLONE_NEWUTS and CLONE_NEWIPC
Remove question mark: s/New utsname group?/New utsname namespace Unified style for IPC: s/New ipcs/New ipc namespace Signed-off-by: Chen Hanxiao --- include/uapi/linux/sched.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/include/uapi/linux/sched.h b/include/uapi/linux/sched.h index b932be9..cc89dde 100644 --- a/include/uapi/linux/sched.h +++ b/include/uapi/linux/sched.h @@ -23,8 +23,8 @@ #define CLONE_CHILD_SETTID 0x0100 /* set the TID in the child */ /* 0x0200 was previously the unused CLONE_STOPPED (Start in stopped state) and is now available for re-use. */ -#define CLONE_NEWUTS 0x0400 /* New utsname group? */ -#define CLONE_NEWIPC 0x0800 /* New ipcs */ +#define CLONE_NEWUTS 0x0400 /* New utsname namespace */ +#define CLONE_NEWIPC 0x0800 /* New ipc namespace */ #define CLONE_NEWUSER 0x1000 /* New user namespace */ #define CLONE_NEWPID 0x2000 /* New pid namespace */ #define CLONE_NEWNET 0x4000 /* New network namespace */ -- 1.9.3 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCHv5] procfs: show hierarchy of pid namespace
> -Original Message-
> From: se...@hallyn.com [mailto:se...@hallyn.com]
> Sent: Saturday, November 01, 2014 2:31 AM
> To: contain...@lists.linux-foundation.org; linux-kernel@vger.kernel.org; Chen,
> Hanxiao/陈 晗霄
> Cc: Richard Weinberger; Serge Hallyn; Oleg Nesterov; Mateusz Guzik; David
> Howells;
> Eric W. Biederman
> Subject: Re: [PATCHv5] procfs: show hierarchy of pid namespace
>
> If pidns_list_add fails, the get_pid taken in the caller leaks.
>
Will fix in the next patch.
> It's not clear to me that the loop in 'if curns' will always end in a
> list_add_tail,
> and if not the get_pid leaks. It does look like it should, but something to
> catch
> the unexpected failure (especially after someone modifies that code) would be
> nice
The previous version collect all namespace's pids on host,
in one scenario we had to add them into list according to curr_ns;
another scenario we add them into list directly.
But now using find_ge_pid, we only collect pids of current ns,
so these codes are redundant.
Sorry for that mistake.
Thanks,
- Chen
> On 10/16/14 7:01 Chen Hanxiao wrote:
> 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 same 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
> *Note: numbers represent the pid 1 in different ns
>
> It shows the pid hierarchy below:
>
> init_pid_ns (not showed in /proc/pidns_hierarchy)
> │
> ┌┐
> ns1 ns2
> ││
> 155018060
> │
> │
> ns3
> │
> 18102
> │
> ┌──┐
> ns4 ns5
> ││
> 1534 1600
>
> Every pid printed in pidns_hierarchy
> is the init pid of that pid ns level.
>
> Signed-off-by: Chen Hanxiao
> ---
[snip]
N�r��yb�X��ǧv�^�){.n�+{zX����ܨ}���Ơz�:+v���zZ+��+zf���h���~i���z� �w���?�&�)ߢf��^jǫy�m��@A�a���
0��h���i
RE: [PATCHv5] procfs: show hierarchy of pid namespace
-Original Message-
From: se...@hallyn.com [mailto:se...@hallyn.com]
Sent: Saturday, November 01, 2014 2:31 AM
To: contain...@lists.linux-foundation.org; linux-kernel@vger.kernel.org; Chen,
Hanxiao/陈 晗霄
Cc: Richard Weinberger; Serge Hallyn; Oleg Nesterov; Mateusz Guzik; David
Howells;
Eric W. Biederman
Subject: Re: [PATCHv5] procfs: show hierarchy of pid namespace
If pidns_list_add fails, the get_pid taken in the caller leaks.
Will fix in the next patch.
It's not clear to me that the loop in 'if curns' will always end in a
list_add_tail,
and if not the get_pid leaks. It does look like it should, but something to
catch
the unexpected failure (especially after someone modifies that code) would be
nice
The previous version collect all namespace's pids on host,
in one scenario we had to add them into list according to curr_ns;
another scenario we add them into list directly.
But now using find_ge_pid, we only collect pids of current ns,
so these codes are redundant.
Sorry for that mistake.
Thanks,
- Chen
On 10/16/14 7:01 Chen Hanxiao wrote:
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 same 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
*Note: numbers represent the pid 1 in different ns
It shows the pid hierarchy below:
init_pid_ns (not showed in /proc/pidns_hierarchy)
│
┌┐
ns1 ns2
││
155018060
│
│
ns3
│
18102
│
┌──┐
ns4 ns5
││
1534 1600
Every pid printed in pidns_hierarchy
is the init pid of that pid ns level.
Signed-off-by: Chen Hanxiao chenhanx...@cn.fujitsu.com
---
[snip]
N�r��yb�X��ǧv�^�){.n�+{zX����ܨ}���Ơz�j:+v���zZ+��+zf���h���~i���z� �w���?��)ߢf��^jǫy�m��@A�a���
0��h���i
[PATCH] sched: updated comments of CLONE_NEWUTS and CLONE_NEWIPC
Remove question mark: s/New utsname group?/New utsname namespace Unified style for IPC: s/New ipcs/New ipc namespace Signed-off-by: Chen Hanxiao chenhanx...@cn.fujitsu.com --- include/uapi/linux/sched.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/include/uapi/linux/sched.h b/include/uapi/linux/sched.h index b932be9..cc89dde 100644 --- a/include/uapi/linux/sched.h +++ b/include/uapi/linux/sched.h @@ -23,8 +23,8 @@ #define CLONE_CHILD_SETTID 0x0100 /* set the TID in the child */ /* 0x0200 was previously the unused CLONE_STOPPED (Start in stopped state) and is now available for re-use. */ -#define CLONE_NEWUTS 0x0400 /* New utsname group? */ -#define CLONE_NEWIPC 0x0800 /* New ipcs */ +#define CLONE_NEWUTS 0x0400 /* New utsname namespace */ +#define CLONE_NEWIPC 0x0800 /* New ipc namespace */ #define CLONE_NEWUSER 0x1000 /* New user namespace */ #define CLONE_NEWPID 0x2000 /* New pid namespace */ #define CLONE_NEWNET 0x4000 /* New network namespace */ -- 1.9.3 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[tip:sched/core] sched: Update comments for CLONE_NEWNS
Commit-ID: fcd964dda5ece2fa77f78f843bc3455348787282 Gitweb: http://git.kernel.org/tip/fcd964dda5ece2fa77f78f843bc3455348787282 Author: Chen Hanxiao AuthorDate: Tue, 7 Oct 2014 17:29:07 +0800 Committer: Ingo Molnar CommitDate: Tue, 28 Oct 2014 10:46:08 +0100 sched: Update comments for CLONE_NEWNS Signed-off-by: Chen Hanxiao Acked-by: Serge E. Hallyn Signed-off-by: Peter Zijlstra (Intel) Cc: Linus Torvalds Cc: linux-...@vger.kernel.org Link: http://lkml.kernel.org/r/1412674147-8941-1-git-send-email-chenhanx...@cn.fujitsu.com Signed-off-by: Ingo Molnar --- include/uapi/linux/sched.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/uapi/linux/sched.h b/include/uapi/linux/sched.h index 34f9d73..b932be9 100644 --- a/include/uapi/linux/sched.h +++ b/include/uapi/linux/sched.h @@ -13,7 +13,7 @@ #define CLONE_VFORK0x4000 /* set if the parent wants the child to wake it up on mm_release */ #define CLONE_PARENT 0x8000 /* set if we want to have the same parent as the cloner */ #define CLONE_THREAD 0x0001 /* Same thread group? */ -#define CLONE_NEWNS0x0002 /* New namespace group? */ +#define CLONE_NEWNS0x0002 /* New mount namespace group */ #define CLONE_SYSVSEM 0x0004 /* share system V SEM_UNDO semantics */ #define CLONE_SETTLS 0x0008 /* create a new TLS for the child */ #define CLONE_PARENT_SETTID0x0010 /* set the TID in the parent */ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [RESEND][PATCH 0/2v5] ns, procfs: pid conversion between ns and showing pidns hierarchy
> -Original Message- > From: containers-boun...@lists.linux-foundation.org > [mailto:containers-boun...@lists.linux-foundation.org] On Behalf Of Chen > Hanxiao > Sent: Friday, October 24, 2014 6:16 PM > To: contain...@lists.linux-foundation.org; linux-kernel@vger.kernel.org > Cc: Richard Weinberger; Serge Hallyn; Oleg Nesterov; Mateusz Guzik; David > Howells; > Eric W. Biederman > Subject: [RESEND][PATCH 0/2v5] ns, procfs: pid conversion between ns and > showing > pidns hierarchy > > This series will expose pid inside containers > via procfs. > Also show the hierarchy of pid namespcae. > Then we could know how pid looks inside a container > and their ns relationships. > > 1. helpful for nested container check/restore > From /proc/PID/ns/pid, we could know whether two pid lived > in the same ns. > From this patch, we could know whether two pid had relationship > between each other. > > 2. used for pid translation from container > Ex: > init_pid_nsns1 ns2 > t1 2 > t2 `- 3 1 > t3 `- 4 3 > t4 `- 5 `- 51 > t5 `- 6 `- 83 > > It could solve problems like: we see a pid 3 goes wrong > in container's log, what is its pid on hosts: > a) inside container: > # readlink /proc/3/ns/pid > pid:[4026532388] > > b) on host: > # cat /proc/pidns_hierarchy > 14918 16263 > 16581 > Then we could easily find /proc/16263/ns/pid->4026532388. > On host, we knew that reported pid 3 is in level 2, >and its parental pid ns is from pid 14918. > > c) on host, check child of 16263, grep it from status: > NSpid: 16268 8 3 > > We knew that pid 16268 is pid 3 reported by container. > Hi, Any comments? Thanks, - Chen
RE: [RESEND][PATCH 0/2v5] ns, procfs: pid conversion between ns and showing pidns hierarchy
-Original Message- From: containers-boun...@lists.linux-foundation.org [mailto:containers-boun...@lists.linux-foundation.org] On Behalf Of Chen Hanxiao Sent: Friday, October 24, 2014 6:16 PM To: contain...@lists.linux-foundation.org; linux-kernel@vger.kernel.org Cc: Richard Weinberger; Serge Hallyn; Oleg Nesterov; Mateusz Guzik; David Howells; Eric W. Biederman Subject: [RESEND][PATCH 0/2v5] ns, procfs: pid conversion between ns and showing pidns hierarchy This series will expose pid inside containers via procfs. Also show the hierarchy of pid namespcae. Then we could know how pid looks inside a container and their ns relationships. 1. helpful for nested container check/restore From /proc/PID/ns/pid, we could know whether two pid lived in the same ns. From this patch, we could know whether two pid had relationship between each other. 2. used for pid translation from container Ex: init_pid_nsns1 ns2 t1 2 t2 `- 3 1 t3 `- 4 3 t4 `- 5 `- 51 t5 `- 6 `- 83 It could solve problems like: we see a pid 3 goes wrong in container's log, what is its pid on hosts: a) inside container: # readlink /proc/3/ns/pid pid:[4026532388] b) on host: # cat /proc/pidns_hierarchy 14918 16263 16581 Then we could easily find /proc/16263/ns/pid-4026532388. On host, we knew that reported pid 3 is in level 2, and its parental pid ns is from pid 14918. c) on host, check child of 16263, grep it from status: NSpid: 16268 8 3 We knew that pid 16268 is pid 3 reported by container. Hi, Any comments? Thanks, - Chen
[tip:sched/core] sched: Update comments for CLONE_NEWNS
Commit-ID: fcd964dda5ece2fa77f78f843bc3455348787282 Gitweb: http://git.kernel.org/tip/fcd964dda5ece2fa77f78f843bc3455348787282 Author: Chen Hanxiao chenhanx...@cn.fujitsu.com AuthorDate: Tue, 7 Oct 2014 17:29:07 +0800 Committer: Ingo Molnar mi...@kernel.org CommitDate: Tue, 28 Oct 2014 10:46:08 +0100 sched: Update comments for CLONE_NEWNS Signed-off-by: Chen Hanxiao chenhanx...@cn.fujitsu.com Acked-by: Serge E. Hallyn serge.hal...@ubuntu.com Signed-off-by: Peter Zijlstra (Intel) pet...@infradead.org Cc: Linus Torvalds torva...@linux-foundation.org Cc: linux-...@vger.kernel.org Link: http://lkml.kernel.org/r/1412674147-8941-1-git-send-email-chenhanx...@cn.fujitsu.com Signed-off-by: Ingo Molnar mi...@kernel.org --- include/uapi/linux/sched.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/uapi/linux/sched.h b/include/uapi/linux/sched.h index 34f9d73..b932be9 100644 --- a/include/uapi/linux/sched.h +++ b/include/uapi/linux/sched.h @@ -13,7 +13,7 @@ #define CLONE_VFORK0x4000 /* set if the parent wants the child to wake it up on mm_release */ #define CLONE_PARENT 0x8000 /* set if we want to have the same parent as the cloner */ #define CLONE_THREAD 0x0001 /* Same thread group? */ -#define CLONE_NEWNS0x0002 /* New namespace group? */ +#define CLONE_NEWNS0x0002 /* New mount namespace group */ #define CLONE_SYSVSEM 0x0004 /* share system V SEM_UNDO semantics */ #define CLONE_SETTLS 0x0008 /* create a new TLS for the child */ #define CLONE_PARENT_SETTID0x0010 /* set the TID in the parent */ -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RESEND][PATCH 0/2v5] ns, procfs: pid conversion between ns and showing pidns hierarchy
This series will expose pid inside containers via procfs. Also show the hierarchy of pid namespcae. Then we could know how pid looks inside a container and their ns relationships. 1. helpful for nested container check/restore >From /proc/PID/ns/pid, we could know whether two pid lived in the same ns. >From this patch, we could know whether two pid had relationship between each other. 2. used for pid translation from container Ex: init_pid_nsns1 ns2 t1 2 t2 `- 3 1 t3 `- 4 3 t4 `- 5 `- 51 t5 `- 6 `- 83 It could solve problems like: we see a pid 3 goes wrong in container's log, what is its pid on hosts: a) inside container: # readlink /proc/3/ns/pid pid:[4026532388] b) on host: # cat /proc/pidns_hierarchy 14918 16263 16581 Then we could easily find /proc/16263/ns/pid->4026532388. On host, we knew that reported pid 3 is in level 2, and its parental pid ns is from pid 14918. c) on host, check child of 16263, grep it from status: NSpid: 16268 8 3 We knew that pid 16268 is pid 3 reported by container. v5: collect pid by find_ge_pid; use local list inside nslist_proc_show; use get_pid, remove mutex lock. v4: simplify pid collection and some performance optimizamtion fix another race issue. v3: fix a race issue and memory leak issue in pidns_hierarchy; add another two fielsd: NSpgid and NSsid. v2: use a procfs text file instead of dirs under /proc for showing pidns hierarchy; add two new fields: NStgid and NSpid keep fields of Tgid and Pid unchanged for back compatibility. Chen Hanxiao (2): procfs: show hierarchy of pid namespace /proc/PID/status: show all sets of pid according to ns fs/proc/Kconfig | 6 ++ fs/proc/Makefile | 1 + fs/proc/array.c | 17 fs/proc/pidns_hierarchy.c | 226 ++ 4 files changed, 250 insertions(+) create mode 100644 fs/proc/pidns_hierarchy.c -- 1.9.3 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RESEND][PATCH 1/2v5] procfs: show hierarchy of pid namespace
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
*Note: numbers represent the pid 1 in different ns
It shows the pid hierarchy below:
init_pid_ns (not showed in /proc/pidns_hierarchy)
│
┌┐
ns1 ns2
││
155018060
│
│
ns3
│
18102
│
┌──┐
ns4 ns5
││
1534 1600
Every pid printed in pidns_hierarchy
is the init pid of that pid ns level.
Signed-off-by: Chen Hanxiao
---
fs/proc/Kconfig | 6 ++
fs/proc/Makefile | 1 +
fs/proc/pidns_hierarchy.c | 226 ++
3 files changed, 233 insertions(+)
create mode 100644 fs/proc/pidns_hierarchy.c
diff --git a/fs/proc/Kconfig b/fs/proc/Kconfig
index 2183fcf..4bb111c 100644
--- a/fs/proc/Kconfig
+++ b/fs/proc/Kconfig
@@ -71,3 +71,9 @@ config PROC_PAGE_MONITOR
/proc/pid/smaps, /proc/pid/clear_refs, /proc/pid/pagemap,
/proc/kpagecount, and /proc/kpageflags. Disabling these
interfaces will reduce the size of the kernel by approximately 4kb.
+
+config PROC_PID_HIERARCHY
+ bool "Enable /proc/pidns_hierarchy support" if EXPERT
+ depends on PROC_FS
+ help
+ Show pid namespace hierarchy information
diff --git a/fs/proc/Makefile b/fs/proc/Makefile
index 7151ea4..33e384b 100644
--- a/fs/proc/Makefile
+++ b/fs/proc/Makefile
@@ -30,3 +30,4 @@ proc-$(CONFIG_PROC_KCORE) += kcore.o
proc-$(CONFIG_PROC_VMCORE) += vmcore.o
proc-$(CONFIG_PRINTK) += kmsg.o
proc-$(CONFIG_PROC_PAGE_MONITOR) += page.o
+proc-$(CONFIG_PROC_PID_HIERARCHY) += pidns_hierarchy.o
diff --git a/fs/proc/pidns_hierarchy.c b/fs/proc/pidns_hierarchy.c
new file mode 100644
index 000..2f5148c
--- /dev/null
+++ b/fs/proc/pidns_hierarchy.c
@@ -0,0 +1,226 @@
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+/*
+ * /proc/pidns_hierarchy
+ *
+ * show the hierarchy of pid namespace
+ */
+
+#define NS_HIERARCHY "pidns_hierarchy"
+
+/* list for host pid collection */
+struct pidns_list {
+ struct list_head list;
+ struct pid *pid;
+};
+
+static void free_pidns_list(struct list_head *head)
+{
+ struct pidns_list *tmp, *pos;
+
+ list_for_each_entry_safe(pos, tmp, head, list) {
+ list_del(>list);
+ put_pid(pos->pid);
+ kfree(pos);
+ }
+}
+
+static int
+pidns_list_add(struct pid *pid, struct list_head *list_head,
+ struct pid_namespace *curr_ns)
+{
+ struct pidns_list *ent;
+ struct pid_namespace *ns;
+
+ ent = kmalloc(sizeof(*ent), GFP_KERNEL);
+ if (!ent)
+ return -ENOMEM;
+
+ ent->pid = pid;
+ ns = pid->numbers[pid->level].ns;
+ if (curr_ns) {
+ /* add pids who is the child of curr_ns */
+ for (; ns != NULL; ns = ns->parent)
+ if (ns == curr_ns) {
+ list_add_tail(>list, list_head);
+ break;
+ }
+ } else
+ list_add_tail(>list, list_head);
+
+ return 0;
+}
+
+static int
+pidns_list_filter(struct list_head *pidns_list,
+ struct list_head *pidns_tree)
+{
+ struct pidns_list *pos, *pos_t;
+ struct pid_namespace *ns0, *ns1;
+ struct pid *pid0, *pid1;
+ int rc, flag = 0;
+
+ /* screen pid with relationship
+* in pidns_list, we may add pids like
+* ns0 ns1 ns2
+* pid1->pid2->pid3
+* we should screen pid1, pid2 and keep pid3
+*/
+ list_for_each_entry(pos, pidns_list, list) {
+ list_for_each_entry(pos_t, pidns_list, list) {
+ flag = 0;
+ pid0 = pos->pid;
+ pid1 = pos_t->pid;
+ ns0 = pid0->numbers[pid0->level].ns;
+ ns1 = pid1->numbers[pid1->level].ns;
+ if (pos->pid->level < pos_t->pid->level)
+ for (; ns1 != NULL; ns1 = ns1->parent)
+ if (ns0 == ns1) {
+
[RESEND][PATCH 2/2v5] /proc/PID/status: show all sets of pid according to ns
If some issues occurred inside a 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 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 Acked-by: Serge Hallyn Tested-by: Serge Hallyn Signed-off-by: Chen Hanxiao --- fs/proc/array.c | 17 + 1 file changed, 17 insertions(+) diff --git a/fs/proc/array.c b/fs/proc/array.c index cd3653e..c30875d 100644 --- a/fs/proc/array.c +++ b/fs/proc/array.c @@ -193,6 +193,23 @@ static inline void task_state(struct seq_file *m, struct pid_namespace *ns, from_kgid_munged(user_ns, cred->egid), from_kgid_munged(user_ns, cred->sgid), from_kgid_munged(user_ns, cred->fsgid)); + seq_puts(m, "NStgid:"); + for (g = ns->level; g <= pid->level; g++) + seq_printf(m, "\t%d ", + task_tgid_nr_ns(p, pid->numbers[g].ns)); + seq_puts(m, "\nNSpid:"); + for (g = ns->level; g <= pid->level; g++) + seq_printf(m, "\t%d ", + task_pid_nr_ns(p, pid->numbers[g].ns)); + seq_puts(m, "\nNSpgid:"); + for (g = ns->level; g <= pid->level; g++) + seq_printf(m, "\t%d ", + task_pgrp_nr_ns(p, pid->numbers[g].ns)); + seq_puts(m, "\nNSsid:"); + for (g = ns->level; g <= pid->level; g++) + seq_printf(m, "\t%d ", + task_session_nr_ns(p, pid->numbers[g].ns)); + seq_putc(m, '\n'); task_lock(p); if (p->files) -- 1.9.3 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RESEND][PATCH 2/2v5] /proc/PID/status: show all sets of pid according to ns
If some issues occurred inside a 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 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 Acked-by: Serge Hallyn serge.hal...@canonical.com Tested-by: Serge Hallyn serge.hal...@canonical.com Signed-off-by: Chen Hanxiao chenhanx...@cn.fujitsu.com --- fs/proc/array.c | 17 + 1 file changed, 17 insertions(+) diff --git a/fs/proc/array.c b/fs/proc/array.c index cd3653e..c30875d 100644 --- a/fs/proc/array.c +++ b/fs/proc/array.c @@ -193,6 +193,23 @@ static inline void task_state(struct seq_file *m, struct pid_namespace *ns, from_kgid_munged(user_ns, cred-egid), from_kgid_munged(user_ns, cred-sgid), from_kgid_munged(user_ns, cred-fsgid)); + seq_puts(m, NStgid:); + for (g = ns-level; g = pid-level; g++) + seq_printf(m, \t%d , + task_tgid_nr_ns(p, pid-numbers[g].ns)); + seq_puts(m, \nNSpid:); + for (g = ns-level; g = pid-level; g++) + seq_printf(m, \t%d , + task_pid_nr_ns(p, pid-numbers[g].ns)); + seq_puts(m, \nNSpgid:); + for (g = ns-level; g = pid-level; g++) + seq_printf(m, \t%d , + task_pgrp_nr_ns(p, pid-numbers[g].ns)); + seq_puts(m, \nNSsid:); + for (g = ns-level; g = pid-level; g++) + seq_printf(m, \t%d , + task_session_nr_ns(p, pid-numbers[g].ns)); + seq_putc(m, '\n'); task_lock(p); if (p-files) -- 1.9.3 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RESEND][PATCH 1/2v5] procfs: show hierarchy of pid namespace
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
*Note: numbers represent the pid 1 in different ns
It shows the pid hierarchy below:
init_pid_ns (not showed in /proc/pidns_hierarchy)
│
┌┐
ns1 ns2
││
155018060
│
│
ns3
│
18102
│
┌──┐
ns4 ns5
││
1534 1600
Every pid printed in pidns_hierarchy
is the init pid of that pid ns level.
Signed-off-by: Chen Hanxiao chenhanx...@cn.fujitsu.com
---
fs/proc/Kconfig | 6 ++
fs/proc/Makefile | 1 +
fs/proc/pidns_hierarchy.c | 226 ++
3 files changed, 233 insertions(+)
create mode 100644 fs/proc/pidns_hierarchy.c
diff --git a/fs/proc/Kconfig b/fs/proc/Kconfig
index 2183fcf..4bb111c 100644
--- a/fs/proc/Kconfig
+++ b/fs/proc/Kconfig
@@ -71,3 +71,9 @@ config PROC_PAGE_MONITOR
/proc/pid/smaps, /proc/pid/clear_refs, /proc/pid/pagemap,
/proc/kpagecount, and /proc/kpageflags. Disabling these
interfaces will reduce the size of the kernel by approximately 4kb.
+
+config PROC_PID_HIERARCHY
+ bool Enable /proc/pidns_hierarchy support if EXPERT
+ depends on PROC_FS
+ help
+ Show pid namespace hierarchy information
diff --git a/fs/proc/Makefile b/fs/proc/Makefile
index 7151ea4..33e384b 100644
--- a/fs/proc/Makefile
+++ b/fs/proc/Makefile
@@ -30,3 +30,4 @@ proc-$(CONFIG_PROC_KCORE) += kcore.o
proc-$(CONFIG_PROC_VMCORE) += vmcore.o
proc-$(CONFIG_PRINTK) += kmsg.o
proc-$(CONFIG_PROC_PAGE_MONITOR) += page.o
+proc-$(CONFIG_PROC_PID_HIERARCHY) += pidns_hierarchy.o
diff --git a/fs/proc/pidns_hierarchy.c b/fs/proc/pidns_hierarchy.c
new file mode 100644
index 000..2f5148c
--- /dev/null
+++ b/fs/proc/pidns_hierarchy.c
@@ -0,0 +1,226 @@
+#include linux/init.h
+#include linux/errno.h
+#include linux/proc_fs.h
+#include linux/module.h
+#include linux/list.h
+#include linux/slab.h
+#include linux/pid_namespace.h
+#include linux/seq_file.h
+
+/*
+ * /proc/pidns_hierarchy
+ *
+ * show the hierarchy of pid namespace
+ */
+
+#define NS_HIERARCHY pidns_hierarchy
+
+/* list for host pid collection */
+struct pidns_list {
+ struct list_head list;
+ struct pid *pid;
+};
+
+static void free_pidns_list(struct list_head *head)
+{
+ struct pidns_list *tmp, *pos;
+
+ list_for_each_entry_safe(pos, tmp, head, list) {
+ list_del(pos-list);
+ put_pid(pos-pid);
+ kfree(pos);
+ }
+}
+
+static int
+pidns_list_add(struct pid *pid, struct list_head *list_head,
+ struct pid_namespace *curr_ns)
+{
+ struct pidns_list *ent;
+ struct pid_namespace *ns;
+
+ ent = kmalloc(sizeof(*ent), GFP_KERNEL);
+ if (!ent)
+ return -ENOMEM;
+
+ ent-pid = pid;
+ ns = pid-numbers[pid-level].ns;
+ if (curr_ns) {
+ /* add pids who is the child of curr_ns */
+ for (; ns != NULL; ns = ns-parent)
+ if (ns == curr_ns) {
+ list_add_tail(ent-list, list_head);
+ break;
+ }
+ } else
+ list_add_tail(ent-list, list_head);
+
+ return 0;
+}
+
+static int
+pidns_list_filter(struct list_head *pidns_list,
+ struct list_head *pidns_tree)
+{
+ struct pidns_list *pos, *pos_t;
+ struct pid_namespace *ns0, *ns1;
+ struct pid *pid0, *pid1;
+ int rc, flag = 0;
+
+ /* screen pid with relationship
+* in pidns_list, we may add pids like
+* ns0 ns1 ns2
+* pid1-pid2-pid3
+* we should screen pid1, pid2 and keep pid3
+*/
+ list_for_each_entry(pos, pidns_list, list) {
+ list_for_each_entry(pos_t, pidns_list, list) {
+ flag = 0;
+ pid0 = pos-pid;
+ pid1 = pos_t-pid;
+ ns0 = pid0-numbers[pid0-level].ns;
+ ns1 = pid1-numbers[pid1-level].ns;
+ if (pos-pid-level pos_t-pid-level)
+ for (; ns1 != NULL; ns1 = ns1-parent)
+ if (ns0
[RESEND][PATCH 0/2v5] ns, procfs: pid conversion between ns and showing pidns hierarchy
This series will expose pid inside containers via procfs. Also show the hierarchy of pid namespcae. Then we could know how pid looks inside a container and their ns relationships. 1. helpful for nested container check/restore From /proc/PID/ns/pid, we could know whether two pid lived in the same ns. From this patch, we could know whether two pid had relationship between each other. 2. used for pid translation from container Ex: init_pid_nsns1 ns2 t1 2 t2 `- 3 1 t3 `- 4 3 t4 `- 5 `- 51 t5 `- 6 `- 83 It could solve problems like: we see a pid 3 goes wrong in container's log, what is its pid on hosts: a) inside container: # readlink /proc/3/ns/pid pid:[4026532388] b) on host: # cat /proc/pidns_hierarchy 14918 16263 16581 Then we could easily find /proc/16263/ns/pid-4026532388. On host, we knew that reported pid 3 is in level 2, and its parental pid ns is from pid 14918. c) on host, check child of 16263, grep it from status: NSpid: 16268 8 3 We knew that pid 16268 is pid 3 reported by container. v5: collect pid by find_ge_pid; use local list inside nslist_proc_show; use get_pid, remove mutex lock. v4: simplify pid collection and some performance optimizamtion fix another race issue. v3: fix a race issue and memory leak issue in pidns_hierarchy; add another two fielsd: NSpgid and NSsid. v2: use a procfs text file instead of dirs under /proc for showing pidns hierarchy; add two new fields: NStgid and NSpid keep fields of Tgid and Pid unchanged for back compatibility. Chen Hanxiao (2): procfs: show hierarchy of pid namespace /proc/PID/status: show all sets of pid according to ns fs/proc/Kconfig | 6 ++ fs/proc/Makefile | 1 + fs/proc/array.c | 17 fs/proc/pidns_hierarchy.c | 226 ++ 4 files changed, 250 insertions(+) create mode 100644 fs/proc/pidns_hierarchy.c -- 1.9.3 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCHv5] procfs: show hierarchy of pid namespace
> -Original Message- > From: containers-boun...@lists.linux-foundation.org > [mailto:containers-boun...@lists.linux-foundation.org] On Behalf Of Chen > Hanxiao > Sent: Thursday, October 16, 2014 8:02 PM > To: contain...@lists.linux-foundation.org; linux-kernel@vger.kernel.org > Cc: Richard Weinberger; Serge Hallyn; Oleg Nesterov; Mateusz Guzik; David > Howells; > Eric W. Biederman > Subject: [PATCHv5] procfs: show hierarchy of pid namespace > > 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 same 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: > Any comments? Thanks, - Chen
RE: [PATCHv5] procfs: show hierarchy of pid namespace
-Original Message- From: containers-boun...@lists.linux-foundation.org [mailto:containers-boun...@lists.linux-foundation.org] On Behalf Of Chen Hanxiao Sent: Thursday, October 16, 2014 8:02 PM To: contain...@lists.linux-foundation.org; linux-kernel@vger.kernel.org Cc: Richard Weinberger; Serge Hallyn; Oleg Nesterov; Mateusz Guzik; David Howells; Eric W. Biederman Subject: [PATCHv5] procfs: show hierarchy of pid namespace 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 same 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: Any comments? Thanks, - Chen
