[PATCH] coredump: add %T in core_pattern to report the tid

[PATCH] coredump: add %T in core_pattern to report the tid

[Oleg Nesterov]

format_corename() can only pass the leader's pid to the core handler, but
there is no simple way to figure out which thread originated the coredump.

As Jan explains, this also means that there is no simple way to create the
backtrace of the crashed process:

As programs are mostly compiled with implicit gcc -fomit-frame-pointer one
needs program's .eh_frame section (equivalently PT_GNU_EH_FRAME segment) or
.debug_frame section. .debug_frame usually is present only in separate debug
info files usually not even installed on the system.  While .eh_frame is a
part of the executable/library (and it is even always mapped for C++
exceptions unwinding) it no longer has to be present anywhere on the disk
as the program could be upgraded in the meantime and the running instance
has its executable file already unlinked from disk.

One possibility is to echo 0x3f >/proc/*/coredump_filter and dump all the
file-backed memory including the executable's .eh_frame section. But that
can create huge core files, for example even due to mmapped data files.

Other possibility would be to read .eh_frame from /proc/PID/mem at the
core_pattern handler time of the core dump.  For the backtrace one needs to
read the register state first which can be done from core_pattern handler:

	ptrace(PTRACE_SEIZE, tid, 0, PTRACE_O_TRACEEXIT)
	close(0);    // close pipe fd to resume the sleeping dumper
	waitpid();   // should report EXIT
	PTRACE_GETREGS or other requests

The remaining problem is how to get the 'tid' value of the crashed thread.
It could be read from the first NT_PRSTATUS note of the core file but that
makes the core_pattern handler complicated.

Signed-off-by: Jan Kratochvil <jan.kratochvil@redhat.com>
Signed-off-by: Oleg Nesterov <oleg@redhat.com>
---
 Documentation/sysctl/kernel.txt |    1 +
 fs/coredump.c                   |    4 ++++
 2 files changed, 5 insertions(+), 0 deletions(-)

diff --git a/Documentation/sysctl/kernel.txt b/Documentation/sysctl/kernel.txt
index f79eb96..d2aa7f1 100644
--- a/Documentation/sysctl/kernel.txt
+++ b/Documentation/sysctl/kernel.txt
@@ -189,6 +189,7 @@ core_pattern is used to specify a core dumpfile pattern name.
 	%<NUL>	'%' is dropped
 	%%	output one '%'
 	%p	pid
+	%T	tid
 	%P	global pid (init PID namespace)
 	%u	uid
 	%g	gid
diff --git a/fs/coredump.c b/fs/coredump.c
index a93f7e6..1dc6106 100644
--- a/fs/coredump.c
+++ b/fs/coredump.c
@@ -194,6 +194,10 @@ static int format_corename(struct core_name *cn, struct coredump_params *cprm)
 				err = cn_printf(cn, "%d",
 					      task_tgid_vnr(current));
 				break;
+			case 'T':
+				err = cn_printf(cn, "%d",
+					      task_pid_vnr(current));
+				break;
 			/* global pid */
 			case 'P':
 				err = cn_printf(cn, "%d",
-- 
1.5.5.1

Re: [PATCH] coredump: add %T in core_pattern to report the tid

[Oleg Nesterov]

Self-nack after discussion on debug-list, I'll send v2.

If we teach format_corename() to report task_pid_vnr() we should also
allow to report the global tid from the root namespace, at least to
make this consistent with %p/%P.

This means that %T was a bad choice, Martin suggests %i/%I.

On 09/21, Oleg Nesterov wrote:
>
> format_corename() can only pass the leader's pid to the core handler, but
> there is no simple way to figure out which thread originated the coredump.
>
> As Jan explains, this also means that there is no simple way to create the
> backtrace of the crashed process:
>
> As programs are mostly compiled with implicit gcc -fomit-frame-pointer one
> needs program's .eh_frame section (equivalently PT_GNU_EH_FRAME segment) or
> .debug_frame section. .debug_frame usually is present only in separate debug
> info files usually not even installed on the system.  While .eh_frame is a
> part of the executable/library (and it is even always mapped for C++
> exceptions unwinding) it no longer has to be present anywhere on the disk
> as the program could be upgraded in the meantime and the running instance
> has its executable file already unlinked from disk.
>
> One possibility is to echo 0x3f >/proc/*/coredump_filter and dump all the
> file-backed memory including the executable's .eh_frame section. But that
> can create huge core files, for example even due to mmapped data files.
>
> Other possibility would be to read .eh_frame from /proc/PID/mem at the
> core_pattern handler time of the core dump.  For the backtrace one needs to
> read the register state first which can be done from core_pattern handler:
>
> 	ptrace(PTRACE_SEIZE, tid, 0, PTRACE_O_TRACEEXIT)
> 	close(0);    // close pipe fd to resume the sleeping dumper
> 	waitpid();   // should report EXIT
> 	PTRACE_GETREGS or other requests
>
> The remaining problem is how to get the 'tid' value of the crashed thread.
> It could be read from the first NT_PRSTATUS note of the core file but that
> makes the core_pattern handler complicated.
>
> Signed-off-by: Jan Kratochvil <jan.kratochvil@redhat.com>
> Signed-off-by: Oleg Nesterov <oleg@redhat.com>
> ---
>  Documentation/sysctl/kernel.txt |    1 +
>  fs/coredump.c                   |    4 ++++
>  2 files changed, 5 insertions(+), 0 deletions(-)
>
> diff --git a/Documentation/sysctl/kernel.txt b/Documentation/sysctl/kernel.txt
> index f79eb96..d2aa7f1 100644
> --- a/Documentation/sysctl/kernel.txt
> +++ b/Documentation/sysctl/kernel.txt
> @@ -189,6 +189,7 @@ core_pattern is used to specify a core dumpfile pattern name.
>  	%<NUL>	'%' is dropped
>  	%%	output one '%'
>  	%p	pid
> +	%T	tid
>  	%P	global pid (init PID namespace)
>  	%u	uid
>  	%g	gid
> diff --git a/fs/coredump.c b/fs/coredump.c
> index a93f7e6..1dc6106 100644
> --- a/fs/coredump.c
> +++ b/fs/coredump.c
> @@ -194,6 +194,10 @@ static int format_corename(struct core_name *cn, struct coredump_params *cprm)
>  				err = cn_printf(cn, "%d",
>  					      task_tgid_vnr(current));
>  				break;
> +			case 'T':
> +				err = cn_printf(cn, "%d",
> +					      task_pid_vnr(current));
> +				break;
>  			/* global pid */
>  			case 'P':
>  				err = cn_printf(cn, "%d",
> --
> 1.5.5.1
>

[PATCH v2] coredump: add %i/%I in core_pattern to report the tid of the crashed thread

[Oleg Nesterov]

format_corename() can only pass the leader's pid to the core handler, but
there is no simple way to figure out which thread originated the coredump.

As Jan explains, this also means that there is no simple way to create the
backtrace of the crashed process:

As programs are mostly compiled with implicit gcc -fomit-frame-pointer one
needs program's .eh_frame section (equivalently PT_GNU_EH_FRAME segment) or
.debug_frame section. .debug_frame usually is present only in separate debug
info files usually not even installed on the system.  While .eh_frame is a
part of the executable/library (and it is even always mapped for C++
exceptions unwinding) it no longer has to be present anywhere on the disk
as the program could be upgraded in the meantime and the running instance
has its executable file already unlinked from disk.

One possibility is to echo 0x3f >/proc/*/coredump_filter and dump all the
file-backed memory including the executable's .eh_frame section. But that
can create huge core files, for example even due to mmapped data files.

Other possibility would be to read .eh_frame from /proc/PID/mem at the
core_pattern handler time of the core dump.  For the backtrace one needs to
read the register state first which can be done from core_pattern handler:

	ptrace(PTRACE_SEIZE, tid, 0, PTRACE_O_TRACEEXIT)
	close(0);    // close pipe fd to resume the sleeping dumper
	waitpid();   // should report EXIT
	PTRACE_GETREGS or other requests

The remaining problem is how to get the 'tid' value of the crashed thread.
It could be read from the first NT_PRSTATUS note of the core file but that
makes the core_pattern handler complicated.

Unfortunately %t is already used so this patch uses %i/%I.

Signed-off-by: Jan Kratochvil <jan.kratochvil@redhat.com>
Signed-off-by: Oleg Nesterov <oleg@redhat.com>
---
 Documentation/sysctl/kernel.txt |    2 ++
 fs/coredump.c                   |    8 ++++++++
 2 files changed, 10 insertions(+), 0 deletions(-)

diff --git a/Documentation/sysctl/kernel.txt b/Documentation/sysctl/kernel.txt
index f79eb96..57baff5 100644
--- a/Documentation/sysctl/kernel.txt
+++ b/Documentation/sysctl/kernel.txt
@@ -190,6 +190,8 @@ core_pattern is used to specify a core dumpfile pattern name.
 	%%	output one '%'
 	%p	pid
 	%P	global pid (init PID namespace)
+	%i	tid
+	%I	global tid (init PID namespace)
 	%u	uid
 	%g	gid
 	%d	dump mode, matches PR_SET_DUMPABLE and
diff --git a/fs/coredump.c b/fs/coredump.c
index a93f7e6..b5c86ff 100644
--- a/fs/coredump.c
+++ b/fs/coredump.c
@@ -199,6 +199,14 @@ static int format_corename(struct core_name *cn, struct coredump_params *cprm)
 				err = cn_printf(cn, "%d",
 					      task_tgid_nr(current));
 				break;
+			case 'i':
+				err = cn_printf(cn, "%d",
+					      task_pid_vnr(current));
+				break;
+			case 'I':
+				err = cn_printf(cn, "%d",
+					      task_pid_nr(current));
+				break;
 			/* uid */
 			case 'u':
 				err = cn_printf(cn, "%d", cred->uid);
-- 
1.5.5.1

Re: [PATCH v2] coredump: add %i/%I in core_pattern to report the tid of the crashed thread

[Andrew Morton]

On Mon, 22 Sep 2014 19:15:25 +0200 Oleg Nesterov <oleg@redhat.com> wrote:

> format_corename() can only pass the leader's pid to the core handler, but
> there is no simple way to figure out which thread originated the coredump.
> 
> As Jan explains, this also means that there is no simple way to create the
> backtrace of the crashed process:
> 
> As programs are mostly compiled with implicit gcc -fomit-frame-pointer one
> needs program's .eh_frame section (equivalently PT_GNU_EH_FRAME segment) or
> .debug_frame section. .debug_frame usually is present only in separate debug
> info files usually not even installed on the system.  While .eh_frame is a
> part of the executable/library (and it is even always mapped for C++
> exceptions unwinding) it no longer has to be present anywhere on the disk
> as the program could be upgraded in the meantime and the running instance
> has its executable file already unlinked from disk.
> 
> One possibility is to echo 0x3f >/proc/*/coredump_filter and dump all the
> file-backed memory including the executable's .eh_frame section. But that
> can create huge core files, for example even due to mmapped data files.
> 
> Other possibility would be to read .eh_frame from /proc/PID/mem at the
> core_pattern handler time of the core dump.  For the backtrace one needs to
> read the register state first which can be done from core_pattern handler:
> 
> 	ptrace(PTRACE_SEIZE, tid, 0, PTRACE_O_TRACEEXIT)
> 	close(0);    // close pipe fd to resume the sleeping dumper
> 	waitpid();   // should report EXIT
> 	PTRACE_GETREGS or other requests
> 
> The remaining problem is how to get the 'tid' value of the crashed thread.
> It could be read from the first NT_PRSTATUS note of the core file but that
> makes the core_pattern handler complicated.
> 
> Unfortunately %t is already used so this patch uses %i/%I.

Is any userspace actually going to use this?  If so, details?

Am wondering what is driving this change...

Re: [PATCH v2] coredump: add %i/%I in core_pattern to report the tid of the crashed thread

[Martin Milata]

On Tue, Sep 23, 2014 at 16:05:51 -0700, Andrew Morton wrote:
> On Mon, 22 Sep 2014 19:15:25 +0200 Oleg Nesterov <oleg@redhat.com> wrote:
> 
> > format_corename() can only pass the leader's pid to the core handler, but
> > there is no simple way to figure out which thread originated the coredump.
> > 
> > As Jan explains, this also means that there is no simple way to create the
> > backtrace of the crashed process:
> > 
> > As programs are mostly compiled with implicit gcc -fomit-frame-pointer one
> > needs program's .eh_frame section (equivalently PT_GNU_EH_FRAME segment) or
> > .debug_frame section. .debug_frame usually is present only in separate debug
> > info files usually not even installed on the system.  While .eh_frame is a
> > part of the executable/library (and it is even always mapped for C++
> > exceptions unwinding) it no longer has to be present anywhere on the disk
> > as the program could be upgraded in the meantime and the running instance
> > has its executable file already unlinked from disk.
> > 
> > One possibility is to echo 0x3f >/proc/*/coredump_filter and dump all the
> > file-backed memory including the executable's .eh_frame section. But that
> > can create huge core files, for example even due to mmapped data files.
> > 
> > Other possibility would be to read .eh_frame from /proc/PID/mem at the
> > core_pattern handler time of the core dump.  For the backtrace one needs to
> > read the register state first which can be done from core_pattern handler:
> > 
> > 	ptrace(PTRACE_SEIZE, tid, 0, PTRACE_O_TRACEEXIT)
> > 	close(0);    // close pipe fd to resume the sleeping dumper
> > 	waitpid();   // should report EXIT
> > 	PTRACE_GETREGS or other requests
> > 
> > The remaining problem is how to get the 'tid' value of the crashed thread.
> > It could be read from the first NT_PRSTATUS note of the core file but that
> > makes the core_pattern handler complicated.
> > 
> > Unfortunately %t is already used so this patch uses %i/%I.
> 
> Is any userspace actually going to use this?  If so, details?
> 
> Am wondering what is driving this change...

Automatic Bug Reporting Tool [1] is experimenting with this. It is using
elfutils [2] unwinder for generating the backtraces. Apart from not
needing matching executables as mentioned above, another advantage is
that we can get the backtrace without saving the core (which might be
quite large) to disk.

[1] https://github.com/abrt/abrt/wiki/overview
[2] https://fedorahosted.org/elfutils/