From: Thiago Jung Bauermann <thiago.bauermann@linaro.org>
To: Carlos O'Donell <carlos@redhat.com>
Cc: Alejandro Colomar <alx@kernel.org>, linux-man@vger.kernel.org
Subject: Re: [PATCH] man/man2/sigaction.2: Update si_code list with Linux v6.16
Date: Wed, 03 Sep 2025 00:08:41 -0300 [thread overview]
Message-ID: <87h5xkgrly.fsf@linaro.org> (raw)
In-Reply-To: <66a84774-0c5b-4dc1-af25-1e6d35e3e5ef@redhat.com> (Carlos O'Donell's message of "Fri, 29 Aug 2025 07:56:07 -0400")
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
next prev parent reply other threads:[~2025-09-03 3:08 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-08-28 21:07 [PATCH] man/man2/sigaction.2: Update si_code list with Linux v6.16 Thiago Jung Bauermann
2025-08-29 11:56 ` Carlos O'Donell
2025-09-03 3:08 ` Thiago Jung Bauermann [this message]
2025-09-03 15:37 ` Carlos O'Donell
2025-09-09 3:13 ` Thiago Jung Bauermann
2025-09-09 6:32 ` Alejandro Colomar
2025-09-09 18:26 ` Carlos O'Donell
2025-09-09 18:58 ` Alejandro Colomar
2025-09-09 19:15 ` Thiago Jung Bauermann
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87h5xkgrly.fsf@linaro.org \
--to=thiago.bauermann@linaro.org \
--cc=alx@kernel.org \
--cc=carlos@redhat.com \
--cc=linux-man@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.