[PATCH] man/man2/sigaction.2: Update si_code list with Linux v6.16

[PATCH] man/man2/sigaction.2: Update si_code list with Linux v6.16

[Thiago Jung Bauermann]

Update with missing si_code values from Linux v6.16's
include/uapi/asm-generic/siginfo.h.

Signed-off-by: Thiago Jung Bauermann <thiago.bauermann@linaro.org>
---
 man/man2/sigaction.2 | 49 +++++++++++++++++++++++++++++++++++++++++++-
 1 file changed, 48 insertions(+), 1 deletion(-)

diff --git a/man/man2/sigaction.2 b/man/man2/sigaction.2
index 8d08a8c409d9..1e8ae0b41ea7 100644
--- a/man/man2/sigaction.2
+++ b/man/man2/sigaction.2
@@ -652,6 +652,9 @@ or
 .\" SI_DETHREAD is defined in Linux 2.6.9 sources, but isn't implemented
 .\" It appears to have been an idea that was tried during 2.5.6
 .\" through to Linux 2.5.24 and then was backed out.
+.TP
+.B SI_ASYNCNL
+Async name lookup completion.
 .RE
 .P
 The following values can be placed in
@@ -716,6 +719,12 @@ Floating-point invalid operation.
 .TP
 .B FPE_FLTSUB
 Subscript out of range.
+.TP
+.B FPE_FLTUNK " (since Linux 4.17)"
+Undiagnosed floating-point exception.
+.TP
+.B FPE_CONDTRAP " (PARISC only)"
+Trap on condition.
 .RE
 .P
 The following values can be placed in
@@ -742,6 +751,24 @@ See
 .BR pkeys (7).
 The protection key which applied to this access is available via
 .IR si_pkey .
+.TP
+.B SEGV_ACCADI " (since Linux 4.17, SPARC only)"
+Application Data Integrity not enabled for mapped object.
+.TP
+.B SEGV_ADIDERR " (since Linux 4.17, SPARC only)"
+Disrupting Memory Corruption Detection error.
+.TP
+.B SEGV_ADIPERR " (since Linux 4.17, SPARC only)"
+Precise Memory Corruption Detection exception.
+.TP
+.B SEGV_MTEAERR " (since Linux 5.10, ARM only)"
+Asynchronous Memory Tagging Extension error.
+.TP
+.B SEGV_MTESERR " (since Linux 5.10, ARM only)"
+Synchronous Memory Tagging Extension exception.
+.TP
+.B SEGV_CPERR " (since Linux 6.10)"
+Control protection fault.
 .RE
 .P
 The following values can be placed in
@@ -785,6 +812,12 @@ Process taken branch trap.
 .TP
 .BR TRAP_HWBKPT " (since Linux 2.4, IA64 only)"
 Hardware breakpoint/watchpoint.
+.TP
+.BR TRAP_UNK " (since Linux 4.18)"
+Undiagnosed trap.
+.TP
+.BR TRAP_PERF " (since Linux 5.13)"
+Perf event with sigtrap=1.
 .RE
 .P
 The following values can be placed in
@@ -839,7 +872,7 @@ High priority input available.
 Device disconnected.
 .RE
 .P
-The following value can be placed in
+The following values can be placed in
 .I si_code
 for a
 .B SIGSYS
@@ -850,6 +883,20 @@ signal:
 Triggered by a
 .BR seccomp (2)
 filter rule.
+.TP
+.BR SYS_USER_DISPATCH  " (since Linux 5.11)"
+Syscall user dispatch triggered.
+.RE
+.P
+The following value can be placed in
+.I si_code
+for a
+.B SIGEMT
+signal:
+.RS 4
+.TP
+.BR EMT_TAGOVF " (SPARC only)"
+Tag overflow.
 .RE
 .SS Dynamically probing for flag bit support
 The

base-commit: c7e6c703f8c41d16630dfeb289de6bb45228d8d8

Re: [PATCH] man/man2/sigaction.2: Update si_code list with Linux v6.16

[Carlos O'Donell]

On 8/28/25 5:07 PM, Thiago Jung Bauermann wrote:
> Update with missing si_code values from Linux v6.16's
> include/uapi/asm-generic/siginfo.h.

The top-level header would be "#include <linux/signal.h>"

This header isn't used by a glibc-based userspace.

I've added it to the list of known conflicts:
https://sourceware.org/glibc/wiki/Synchronizing_Headers

Instead /usr/include/bits/siginfo-consts.h (glibc) provides
constants that meet the language and platform requirements.

While it is possible to use the Linux kernel's signal.h directly,
that isn't recommended if you're trying to achieve any level of
language or runtime conformance.

You certainly cannot use "#include <signal.h>" and expect all that
you have written below to work.

I am reviewing those entries which work and those which don't.

If we want the other values to work then someone needs to do the
harder work of either:

  (a) Adding the constants to C libraries in a conformant way.

  (b) Cleaning up the UAPI header to be conforming and work with
      the existing C libraries to include it indirectly.

  (c) Cleaning up both headers to allow dual inclusion with
      additional constants showing up as needed.

In summary:

  - This patch contains 2 constants that don't work today in a glibc-based
    userspace.

  - The existing man page documents 1 constants that doesn't work today
    with the standard #include <signal.h>.

> 
> Signed-off-by: Thiago Jung Bauermann <thiago.bauermann@linaro.org>
> ---
>   man/man2/sigaction.2 | 49 +++++++++++++++++++++++++++++++++++++++++++-
>   1 file changed, 48 insertions(+), 1 deletion(-)
> 
> diff --git a/man/man2/sigaction.2 b/man/man2/sigaction.2
> index 8d08a8c409d9..1e8ae0b41ea7 100644
> --- a/man/man2/sigaction.2
> +++ b/man/man2/sigaction.2
> @@ -652,6 +652,9 @@ or
>   .\" SI_DETHREAD is defined in Linux 2.6.9 sources, but isn't implemented
>   .\" It appears to have been an idea that was tried during 2.5.6
>   .\" through to Linux 2.5.24 and then was backed out.
> +.TP
> +.B SI_ASYNCNL
> +Async name lookup completion.

OK. Present since a992f506ff7 (2016) in glibc, and kernel and glibc constants match.

>   .RE
>   .P
>   The following values can be placed in
> @@ -716,6 +719,12 @@ Floating-point invalid operation.
>   .TP
>   .B FPE_FLTSUB
>   Subscript out of range.
> +.TP
> +.B FPE_FLTUNK " (since Linux 4.17)"
> +Undiagnosed floating-point exception.

OK. Present since 89983cb37c9 (2018) in glibc, and kernel and glibc constants match.

> +.TP
> +.B FPE_CONDTRAP " (PARISC only)"
> +Trap on condition.

OK. Likewise.

>   .RE
>   .P
>   The following values can be placed in
> @@ -742,6 +751,24 @@ See
>   .BR pkeys (7).
>   The protection key which applied to this access is available via
>   .IR si_pkey .
> +.TP
> +.B SEGV_ACCADI " (since Linux 4.17, SPARC only)"
> +Application Data Integrity not enabled for mapped object.
> +.TP
> +.B SEGV_ADIDERR " (since Linux 4.17, SPARC only)"
> +Disrupting Memory Corruption Detection error.
> +.TP

OK. Present since 89983cb37c9 (2018) in glibc.

> +.B SEGV_ADIPERR " (since Linux 4.17, SPARC only)"
> +Precise Memory Corruption Detection exception.
> +.TP

OK. Likewise.

> +.B SEGV_MTEAERR " (since Linux 5.10, ARM only)"
> +Asynchronous Memory Tagging Extension error.
> +.TP
> +.B SEGV_MTESERR " (since Linux 5.10, ARM only)"
> +Synchronous Memory Tagging Extension exception.
> +.TP

OK. Present since 3016596a819 (2021) in glibc.

> +.B SEGV_CPERR " (since Linux 6.10)"
> +Control protection fault.

OK. Present since ac79930498d (2023) in  glibc.

>   .RE
>   .P
>   The following values can be placed in
> @@ -785,6 +812,12 @@ Process taken branch trap.
>   .TP
>   .BR TRAP_HWBKPT " (since Linux 2.4, IA64 only)"
>   Hardware breakpoint/watchpoint.
> +.TP
> +.BR TRAP_UNK " (since Linux 4.18)"
> +Undiagnosed trap.

OK. Present since 89983cb37c9 (2018) in glibc.

> +.TP
> +.BR TRAP_PERF " (since Linux 5.13)"
> +Perf event with sigtrap=1.

Not present in glibc.

Suggest sending a patch to libc-alpha@sourceware.org to patch
glibc/sysdeps/unix/sysv/linux/bits/siginfo-consts.h with the
added constant.

Not directly usable by glibc-based userspace.

>   .RE
>   .P
>   The following values can be placed in
> @@ -839,7 +872,7 @@ High priority input available.
>   Device disconnected.
>   .RE
>   .P
> -The following value can be placed in
> +The following values can be placed in

OK.

>   .I si_code
>   for a
>   .B SIGSYS
> @@ -850,6 +883,20 @@ signal:
>   Triggered by a
>   .BR seccomp (2)
>   filter rule.

^^^^ the existing discussed SYS_SECCOMP is not exposed either and thus
is a documentation issue with this man page.

> +.TP
> +.BR SYS_USER_DISPATCH  " (since Linux 5.11)"
> +Syscall user dispatch triggered.

Not present in glibc.

Not directly usable by glibc-based userspace.

Suggest sending a patch to libc-alpha@sourceware.org to patch
glibc/sysdeps/unix/sysv/linux/bits/siginfo-consts.h with the
added constant along with SYS_SECCOMP which is missing.

This along with the other changes would bring userspace in line with
the kernel constants.

Note: glibc accepts DCOd contributions.
https://sourceware.org/glibc/wiki/Contribution%20checklist

> +.RE
> +.P
> +The following value can be placed in
> +.I si_code
> +for a
> +.B SIGEMT

OK. Present in glibc as an architecture-specific signal (very old).

> +signal:
> +.RS 4
> +.TP
> +.BR EMT_TAGOVF " (SPARC only)"

OK. Present since a992f506ff7 (2016) at least though likely earlier.

> +Tag overflow.
>   .RE
>   .SS Dynamically probing for flag bit support
>   The
> 
> base-commit: c7e6c703f8c41d16630dfeb289de6bb45228d8d8
> 


-- 
Cheers,
Carlos.

Re: [PATCH] man/man2/sigaction.2: Update si_code list with Linux v6.16

[Thiago Jung Bauermann]

Hello,

Carlos O'Donell <carlos@redhat.com> writes:

> On 8/28/25 5:07 PM, Thiago Jung Bauermann wrote:
>> Update with missing si_code values from Linux v6.16's
>> include/uapi/asm-generic/siginfo.h.
>
> The top-level header would be "#include <linux/signal.h>"
>
> This header isn't used by a glibc-based userspace.
>
> I've added it to the list of known conflicts:
> https://sourceware.org/glibc/wiki/Synchronizing_Headers
>
> Instead /usr/include/bits/siginfo-consts.h (glibc) provides
> constants that meet the language and platform requirements.
>
> While it is possible to use the Linux kernel's signal.h directly,
> that isn't recommended if you're trying to achieve any level of
> language or runtime conformance.
>
> You certainly cannot use "#include <signal.h>" and expect all that
> you have written below to work.

I used the kernel's siginfo.h file as a reference of what a process can
potentially see in the si_code field when it gets a signal.

> I am reviewing those entries which work and those which don't.
>
> If we want the other values to work then someone needs to do the
> harder work of either:

To be honest, my motivation to write this patch was just to fix the fact
that SEGV_CPERR was not mentioned. Then I noticed that other constants
were missing too, and thought it would be easy enough to add them as
well...

>  (a) Adding the constants to C libraries in a conformant way.
>
>  (b) Cleaning up the UAPI header to be conforming and work with
>      the existing C libraries to include it indirectly.
>
>  (c) Cleaning up both headers to allow dual inclusion with
>      additional constants showing up as needed.
>
> In summary:
>
>  - This patch contains 2 constants that don't work today in a glibc-based
>    userspace.
>
>  - The existing man page documents 1 constants that doesn't work today
>    with the standard #include <signal.h>.

As you suggested (thanks!), I sent a patch to the glibc mailing list
adding the si_codes it's missing to its siginfo-conts.h header: 

https://inbox.sourceware.org/libc-alpha/20250903024151.3030839-1-thiago.bauermann@linaro.org/

If that one is accepted, hopefully this patch can go in?

>> +.TP
>> +.BR TRAP_PERF " (since Linux 5.13)"
>> +Perf event with sigtrap=1.
>
> Not present in glibc.
>
> Suggest sending a patch to libc-alpha@sourceware.org to patch
> glibc/sysdeps/unix/sysv/linux/bits/siginfo-consts.h with the
> added constant.
>
> Not directly usable by glibc-based userspace.

Added in the glibc patch I just sent.

>> @@ -850,6 +883,20 @@ signal:
>>   Triggered by a
>>   .BR seccomp (2)
>>   filter rule.
>
> ^^^^ the existing discussed SYS_SECCOMP is not exposed either and thus
> is a documentation issue with this man page.

Added in the glibc patch I just sent.

>> +.TP
>> +.BR SYS_USER_DISPATCH  " (since Linux 5.11)"
>> +Syscall user dispatch triggered.
>
> Not present in glibc.
>
> Not directly usable by glibc-based userspace.

Added in the glibc patch I just sent.

> Suggest sending a patch to libc-alpha@sourceware.org to patch
> glibc/sysdeps/unix/sysv/linux/bits/siginfo-consts.h with the
> added constant along with SYS_SECCOMP which is missing.
>
> This along with the other changes would bring userspace in line with
> the kernel constants.
>
> Note: glibc accepts DCOd contributions.
> https://sourceware.org/glibc/wiki/Contribution%20checklist

Thank you for the suggestions. They were very helpful.

-- 
Thiago

Re: [PATCH] man/man2/sigaction.2: Update si_code list with Linux v6.16

[Carlos O'Donell]

On 9/2/25 11:08 PM, Thiago Jung Bauermann wrote:
> To be honest, my motivation to write this patch was just to fix the fact
> that SEGV_CPERR was not mentioned. Then I noticed that other constants
> were missing too, and thought it would be easy enough to add them as
> well...

Welcome to the rabbit hole! :-)
  
>>   (a) Adding the constants to C libraries in a conformant way.
>>
>>   (b) Cleaning up the UAPI header to be conforming and work with
>>       the existing C libraries to include it indirectly.
>>
>>   (c) Cleaning up both headers to allow dual inclusion with
>>       additional constants showing up as needed.
>>
>> In summary:
>>
>>   - This patch contains 2 constants that don't work today in a glibc-based
>>     userspace.
>>
>>   - The existing man page documents 1 constants that doesn't work today
>>     with the standard #include <signal.h>.
> 
> As you suggested (thanks!), I sent a patch to the glibc mailing list
> adding the si_codes it's missing to its siginfo-conts.h header:
> 
> https://inbox.sourceware.org/libc-alpha/20250903024151.3030839-1-thiago.bauermann@linaro.org/
> 
> If that one is accepted, hopefully this patch can go in?

Yes, that works for me.

I've reviewed the glibc submission and it needs a change, but I think we
can get v2 or v3 integrated relatively easily.

-- 
Cheers,
Carlos.

Re: [PATCH] man/man2/sigaction.2: Update si_code list with Linux v6.16

[Thiago Jung Bauermann]

Carlos O'Donell <carlos@redhat.com> writes:

> On 9/2/25 11:08 PM, Thiago Jung Bauermann wrote:
>> To be honest, my motivation to write this patch was just to fix the fact
>> that SEGV_CPERR was not mentioned. Then I noticed that other constants
>> were missing too, and thought it would be easy enough to add them as
>> well...
>
> Welcome to the rabbit hole! :-)

Thanks? :-)

>>>   (a) Adding the constants to C libraries in a conformant way.
>>>
>>>   (b) Cleaning up the UAPI header to be conforming and work with
>>>       the existing C libraries to include it indirectly.
>>>
>>>   (c) Cleaning up both headers to allow dual inclusion with
>>>       additional constants showing up as needed.
>>>
>>> In summary:
>>>
>>>   - This patch contains 2 constants that don't work today in a glibc-based
>>>     userspace.
>>>
>>>   - The existing man page documents 1 constants that doesn't work today
>>>     with the standard #include <signal.h>.
>> As you suggested (thanks!), I sent a patch to the glibc mailing list
>> adding the si_codes it's missing to its siginfo-conts.h header:
>> https://inbox.sourceware.org/libc-alpha/20250903024151.3030839-1-thiago.bauermann@linaro.org/
>> If that one is accepted, hopefully this patch can go in?
>
> Yes, that works for me.

Just FYI to the people on this mailing list, the glibc patch was
committed today.

-- 
Thiago

Re: [PATCH] man/man2/sigaction.2: Update si_code list with Linux v6.16

[Alejandro Colomar]

[-- Attachment #1: Type: text/plain, Size: 1806 bytes --]

Hi Thiago, Carlos,

On Tue, Sep 09, 2025 at 12:13:36AM -0300, Thiago Jung Bauermann wrote:
> Carlos O'Donell <carlos@redhat.com> writes:
> 
> > On 9/2/25 11:08 PM, Thiago Jung Bauermann wrote:
> >> To be honest, my motivation to write this patch was just to fix the fact
> >> that SEGV_CPERR was not mentioned. Then I noticed that other constants
> >> were missing too, and thought it would be easy enough to add them as
> >> well...
> >
> > Welcome to the rabbit hole! :-)
> 
> Thanks? :-)
> 
> >>>   (a) Adding the constants to C libraries in a conformant way.
> >>>
> >>>   (b) Cleaning up the UAPI header to be conforming and work with
> >>>       the existing C libraries to include it indirectly.
> >>>
> >>>   (c) Cleaning up both headers to allow dual inclusion with
> >>>       additional constants showing up as needed.
> >>>
> >>> In summary:
> >>>
> >>>   - This patch contains 2 constants that don't work today in a glibc-based
> >>>     userspace.
> >>>
> >>>   - The existing man page documents 1 constants that doesn't work today
> >>>     with the standard #include <signal.h>.
> >> As you suggested (thanks!), I sent a patch to the glibc mailing list
> >> adding the si_codes it's missing to its siginfo-conts.h header:
> >> https://inbox.sourceware.org/libc-alpha/20250903024151.3030839-1-thiago.bauermann@linaro.org/
> >> If that one is accepted, hopefully this patch can go in?
> >
> > Yes, that works for me.
> 
> Just FYI to the people on this mailing list, the glibc patch was
> committed today.

So, all the things that Carlos said weren't in glibc are now in glibc?
Would you mind adding "(since glibc X.Y)" to them in the patch?


Have a lovely day!
Alex

-- 
<https://www.alejandro-colomar.es>
Use port 80 (that is, <...:80/>).

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH] man/man2/sigaction.2: Update si_code list with Linux v6.16

[Carlos O'Donell]

On 9/9/25 2:32 AM, Alejandro Colomar wrote:
> Hi Thiago, Carlos,
> 
> On Tue, Sep 09, 2025 at 12:13:36AM -0300, Thiago Jung Bauermann wrote:
>> Carlos O'Donell <carlos@redhat.com> writes:
>>
>>> On 9/2/25 11:08 PM, Thiago Jung Bauermann wrote:
>>>> To be honest, my motivation to write this patch was just to fix the fact
>>>> that SEGV_CPERR was not mentioned. Then I noticed that other constants
>>>> were missing too, and thought it would be easy enough to add them as
>>>> well...
>>>
>>> Welcome to the rabbit hole! :-)
>>
>> Thanks? :-)
>>
>>>>>    (a) Adding the constants to C libraries in a conformant way.
>>>>>
>>>>>    (b) Cleaning up the UAPI header to be conforming and work with
>>>>>        the existing C libraries to include it indirectly.
>>>>>
>>>>>    (c) Cleaning up both headers to allow dual inclusion with
>>>>>        additional constants showing up as needed.
>>>>>
>>>>> In summary:
>>>>>
>>>>>    - This patch contains 2 constants that don't work today in a glibc-based
>>>>>      userspace.
>>>>>
>>>>>    - The existing man page documents 1 constants that doesn't work today
>>>>>      with the standard #include <signal.h>.
>>>> As you suggested (thanks!), I sent a patch to the glibc mailing list
>>>> adding the si_codes it's missing to its siginfo-conts.h header:
>>>> https://inbox.sourceware.org/libc-alpha/20250903024151.3030839-1-thiago.bauermann@linaro.org/
>>>> If that one is accepted, hopefully this patch can go in?
>>>
>>> Yes, that works for me.
>>
>> Just FYI to the people on this mailing list, the glibc patch was
>> committed today.
> 
> So, all the things that Carlos said weren't in glibc are now in glibc?

Yes. https://sourceware.org/cgit/glibc/commit/?id=6f120faf649f03a261e3e64d5b5991030383c1b3

> Would you mind adding "(since glibc X.Y)" to them in the patch?

You could write "(since glibc 2.43)" though it won't be released until 2026-02-01.

-- 
Cheers,
Carlos.

Re: [PATCH] man/man2/sigaction.2: Update si_code list with Linux v6.16

[Alejandro Colomar]

[-- Attachment #1: Type: text/plain, Size: 635 bytes --]

Hi Carlos,

On Tue, Sep 09, 2025 at 02:26:10PM -0400, Carlos O'Donell wrote:
> > So, all the things that Carlos said weren't in glibc are now in glibc?
> 
> Yes. https://sourceware.org/cgit/glibc/commit/?id=6f120faf649f03a261e3e64d5b5991030383c1b3

Thanks!

> > Would you mind adding "(since glibc X.Y)" to them in the patch?
> 
> You could write "(since glibc 2.43)" though it won't be released until 2026-02-01.

Yep, that will work.  We can fix the page if the final version number
ends up being different.


Have a lovely night!
Alex

-- 
<https://www.alejandro-colomar.es>
Use port 80 (that is, <...:80/>).

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH] man/man2/sigaction.2: Update si_code list with Linux v6.16

[Thiago Jung Bauermann]

Alejandro Colomar <alx@kernel.org> writes:

> Hi Carlos,
>
> On Tue, Sep 09, 2025 at 02:26:10PM -0400, Carlos O'Donell wrote:
>> > So, all the things that Carlos said weren't in glibc are now in glibc?
>> 
>> Yes. https://sourceware.org/cgit/glibc/commit/?id=6f120faf649f03a261e3e64d5b5991030383c1b3
>
> Thanks!
>
>> > Would you mind adding "(since glibc X.Y)" to them in the patch?
>> 
>> You could write "(since glibc 2.43)" though it won't be released until 2026-02-01.
>
> Yep, that will work.  We can fix the page if the final version number
> ends up being different.

Thanks I just sent a v2 with that change, and also a fix to use .BR
where .B was used incorrectly in v1.
-- 
Thiago