The specifiers supported by core_pattern include the option to indicate the
signal number si_signo by using %s. Other than identifying which signal
generated a core dump (eg: 11 for SIGSEGV), it is useful to know the reason why
a certain signal was sent. The signal code si_code (eg: 2 for SEGV_ACCERR)
provides this information.

Adding the signal code to core_pattern can benefit in particular sysadmins who
pipe core dumps to user-space programs for later analysis. systemd-coredump(8)
is a notable example of such programs.

Signed-off-by: Emanuele Rocca <emanuele.rocca@arm.com>
---
 Documentation/admin-guide/sysctl/kernel.rst | 1 +
 fs/coredump.c                               | 5 +++++
 2 files changed, 6 insertions(+)

diff --git a/Documentation/admin-guide/sysctl/kernel.rst b/Documentation/admin-guide/sysctl/kernel.rst
index 9aed74e65cf4..20177bd94514 100644
--- a/Documentation/admin-guide/sysctl/kernel.rst
+++ b/Documentation/admin-guide/sysctl/kernel.rst
@@ -170,6 +170,7 @@ core_pattern
 	%d		dump mode, matches ``PR_SET_DUMPABLE`` and
 			``/proc/sys/fs/suid_dumpable``
 	%s		signal number
+	%n		signal code
 	%t		UNIX time of dump
 	%h		hostname
 	%e		executable filename (may be shortened, could be changed by prctl etc)
diff --git a/fs/coredump.c b/fs/coredump.c
index 29df8aa19e2e..e78a889fe34c 100644
--- a/fs/coredump.c
+++ b/fs/coredump.c
@@ -400,6 +400,11 @@ static bool coredump_parse(struct core_name *cn, struct coredump_params *cprm,
 				err = cn_printf(cn, "%d",
 						cprm->siginfo->si_signo);
 				break;
+			/* code of the signal that caused the coredump */
+			case 'n':
+				err = cn_printf(cn, "%d",
+						cprm->siginfo->si_code);
+				break;
 			/* UNIX time of coredump */
 			case 't': {
 				time64_t time;
-- 
2.47.3

On Tue, Mar 17, 2026 at 04:00:06PM +0100, Emanuele Rocca wrote:
> The specifiers supported by core_pattern include the option to indicate the
> signal number si_signo by using %s. Other than identifying which signal
> generated a core dump (eg: 11 for SIGSEGV), it is useful to know the reason why
> a certain signal was sent. The signal code si_code (eg: 2 for SEGV_ACCERR)
> provides this information.
> 
> Adding the signal code to core_pattern can benefit in particular sysadmins who
> pipe core dumps to user-space programs for later analysis. systemd-coredump(8)
> is a notable example of such programs.
> 
> Signed-off-by: Emanuele Rocca <emanuele.rocca@arm.com>
> ---
>  Documentation/admin-guide/sysctl/kernel.rst | 1 +
>  fs/coredump.c                               | 5 +++++
>  2 files changed, 6 insertions(+)
> 
> diff --git a/Documentation/admin-guide/sysctl/kernel.rst b/Documentation/admin-guide/sysctl/kernel.rst
> index 9aed74e65cf4..20177bd94514 100644
> --- a/Documentation/admin-guide/sysctl/kernel.rst
> +++ b/Documentation/admin-guide/sysctl/kernel.rst
> @@ -170,6 +170,7 @@ core_pattern
>  	%d		dump mode, matches ``PR_SET_DUMPABLE`` and
>  			``/proc/sys/fs/suid_dumpable``
>  	%s		signal number
> +	%n		signal code

Request %F which installs pidfd for the coredumping process into the
coredump helper then use the pidfd info ioctl in you binary with
PIDFD_INFO_EXIT | PIDFD_INFO_COREDUMP and you can retrieve the exit
status including the signal that was sent to the process.

Hi Christian,

On 2026-03-18 10:45, Christian Brauner wrote:
> Request %F which installs pidfd for the coredumping process into the
> coredump helper then use the pidfd info ioctl in you binary with
> PIDFD_INFO_EXIT | PIDFD_INFO_COREDUMP and you can retrieve the exit
> status including the signal that was sent to the process.

Correct me if I'm wrong, but PIDFD_INFO_COREDUMP seems to be setting
coredump_signal, which is siginfo->si_signo? That information is already
available by using the %s core_pattern specifier anyways.

What I am looking for is si_code instead. Perhaps a field could be added
to struct pidfs_attr and set in fs/pidfs.c similarly to what is currently
done for si_signo?

On Wed, Mar 18, 2026 at 02:17:31PM +0100, Emanuele Rocca wrote:
> Hi Christian,
> 
> On 2026-03-18 10:45, Christian Brauner wrote:
> > Request %F which installs pidfd for the coredumping process into the
> > coredump helper then use the pidfd info ioctl in you binary with
> > PIDFD_INFO_EXIT | PIDFD_INFO_COREDUMP and you can retrieve the exit
> > status including the signal that was sent to the process.
> 
> Correct me if I'm wrong, but PIDFD_INFO_COREDUMP seems to be setting
> coredump_signal, which is siginfo->si_signo? That information is already
> available by using the %s core_pattern specifier anyways.
> 
> What I am looking for is si_code instead. Perhaps a field could be added
> to struct pidfs_attr and set in fs/pidfs.c similarly to what is currently
> done for si_signo?

I see. I don't have a problem with doing that. Let's rope in @Jann and
@Oleg to see whether they have any info-leak/security concerns around
this.