[v2] manual: Update signal descriptions
Checks
Context |
Check |
Description |
redhat-pt-bot/TryBot-apply_patch |
success
|
Patch applied to master at the time it was sent
|
linaro-tcwg-bot/tcwg_glibc_build--master-aarch64 |
success
|
Build passed
|
linaro-tcwg-bot/tcwg_glibc_check--master-aarch64 |
success
|
Test passed
|
linaro-tcwg-bot/tcwg_glibc_build--master-arm |
success
|
Build passed
|
linaro-tcwg-bot/tcwg_glibc_check--master-arm |
success
|
Test passed
|
Commit Message
Based on auditing all the signals and source trees for Hurd and
Linux...
SIGSYS - This is not used for a bad system call (ENOSYS is used
for that). This is used by SECCOMP and some cases where an invalid
sub-function was requested.
SIGSTKFLT - Note it used to be a coprocessor stack fault but is now
obsolete and available for general user use.
SIGLOST - Hurd only now; note that its original purpose as an NFS
lock lost signal is obsolete.
SIGPWR - Note this is for power lost *and* power restored, and is
more a user-mode signal than a kernel-generated signal.
Comments
* DJ Delorie:
> +@deftypevr Macro int SIGPWR
> +@cindex power event signal
> +Power lost or restored. On s390x Linux systems, this signal is
> +generated when a machine check warning is issued, and is sent to the
> +process designated to receive ctrl-alt-del notifications. Otherwise,
> +it is up to userspace applications to generate this signal and manage
> +notifications as to the type of power event that happened.
> +
> +The default action is to terminate the process.
> +@end deftypevr
Stefan, does s390x call these notifications “ctrl-alt-del
notifications”, or this there some other name for them? Is this kernel
code path really active on current systems?
Thanks,
Florian
On Jan 21 2025, Florian Weimer wrote:
> Stefan, does s390x call these notifications “ctrl-alt-del
> notifications”, or this there some other name for them? Is this kernel
> code path really active on current systems?
It is also available as function key 0x020c (Boot) in the vt keyboard
driver, and used by various other drivers in the kernel (look for
kill_cad_pid and ctrl_alt_del).
On 1/21/25 11:14, Andreas Schwab wrote:
> On Jan 21 2025, Florian Weimer wrote:
>
>> Stefan, does s390x call these notifications “ctrl-alt-del
>> notifications”, or this there some other name for them? Is this kernel
>> code path really active on current systems?
>
> It is also available as function key 0x020c (Boot) in the vt keyboard
> driver, and used by various other drivers in the kernel (look for
> kill_cad_pid and ctrl_alt_del).
>
FYI: I've asked around in our kernel-team and the answer:
Yes, the kernel sends SIGPWR on a machine check warning.
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/s390/kernel/nmi.c#n177
Thus the description is fine.
Thanks,
Stefan
* Stefan Liebler:
> On 1/21/25 11:14, Andreas Schwab wrote:
>> On Jan 21 2025, Florian Weimer wrote:
>>
>>> Stefan, does s390x call these notifications “ctrl-alt-del
>>> notifications”, or this there some other name for them? Is this kernel
>>> code path really active on current systems?
>>
>> It is also available as function key 0x020c (Boot) in the vt keyboard
>> driver, and used by various other drivers in the kernel (look for
>> kill_cad_pid and ctrl_alt_del).
>>
>
> FYI: I've asked around in our kernel-team and the answer:
> Yes, the kernel sends SIGPWR on a machine check warning.
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/s390/kernel/nmi.c#n177
>
> Thus the description is fine.
Thanks. Does this include the ctrl-alt-del reference? I thought this
was about a different IBM thing. 8-)
Florian
On 2/3/25 11:52, Florian Weimer wrote:
> * Stefan Liebler:
>
>> On 1/21/25 11:14, Andreas Schwab wrote:
>>> On Jan 21 2025, Florian Weimer wrote:
>>>
>>>> Stefan, does s390x call these notifications “ctrl-alt-del
>>>> notifications”, or this there some other name for them? Is this kernel
>>>> code path really active on current systems?
>>>
>>> It is also available as function key 0x020c (Boot) in the vt keyboard
>>> driver, and used by various other drivers in the kernel (look for
>>> kill_cad_pid and ctrl_alt_del).
>>>
>>
>> FYI: I've asked around in our kernel-team and the answer:
>> Yes, the kernel sends SIGPWR on a machine check warning.
>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/s390/kernel/nmi.c#n177
>>
>> Thus the description is fine.
>
> Thanks. Does this include the ctrl-alt-del reference? I thought this
> was about a different IBM thing. 8-)
>
> Florian
>
We don't exactly know what you mean, but we have:
- kernel/reboot.c:822:void ctrl_alt_del(void)
=> The ctrl_alt_del implementation itself uses "kill_cad_pid(SIGINT,
1);" to send SIGINT to the init process.
- arch/s390/kernel/nmi.c:192: kill_cad_pid(SIGPWR, 1);
=> In case of a machine check warning, "kill_cad_pid(SIGPWR, 1);" is
used to send SIGPWR to the init process (from the SIGPWR-description in
the patch: "to the process designated to receive ctrl-alt-del
notifications").
- drivers/s390/char/sclp_quiesce.c:39: ctrl_alt_del();
=> The signal quiesce is an s390x specific mechanism where HMC or
zVM-hypervisor informs the running kernel that it shall shut down.
Therefore "ctrl_alt_del();" is used which sends SIGINT to the init process.
Thus from my perspective nmi.c is the one for the description of SIGPWR
and the description is fine.
If those information is not the desired one, please ask again with a few
more hints about which ctrl-alt-del reference you mean.
Thanks,
Stefan
* Stefan Liebler:
> On 2/3/25 11:52, Florian Weimer wrote:
>> * Stefan Liebler:
>>
>>> On 1/21/25 11:14, Andreas Schwab wrote:
>>>> On Jan 21 2025, Florian Weimer wrote:
>>>>
>>>>> Stefan, does s390x call these notifications “ctrl-alt-del
>>>>> notifications”, or this there some other name for them? Is this kernel
>>>>> code path really active on current systems?
>>>>
>>>> It is also available as function key 0x020c (Boot) in the vt keyboard
>>>> driver, and used by various other drivers in the kernel (look for
>>>> kill_cad_pid and ctrl_alt_del).
>>>>
>>>
>>> FYI: I've asked around in our kernel-team and the answer:
>>> Yes, the kernel sends SIGPWR on a machine check warning.
>>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/s390/kernel/nmi.c#n177
>>>
>>> Thus the description is fine.
>>
>> Thanks. Does this include the ctrl-alt-del reference? I thought this
>> was about a different IBM thing. 8-)
>>
>> Florian
>>
> We don't exactly know what you mean, but we have:
> - kernel/reboot.c:822:void ctrl_alt_del(void)
> => The ctrl_alt_del implementation itself uses "kill_cad_pid(SIGINT,
> 1);" to send SIGINT to the init process.
>
> - arch/s390/kernel/nmi.c:192: kill_cad_pid(SIGPWR, 1);
> => In case of a machine check warning, "kill_cad_pid(SIGPWR, 1);" is
> used to send SIGPWR to the init process (from the SIGPWR-description in
> the patch: "to the process designated to receive ctrl-alt-del
> notifications").
>
> - drivers/s390/char/sclp_quiesce.c:39: ctrl_alt_del();
> => The signal quiesce is an s390x specific mechanism where HMC or
> zVM-hypervisor informs the running kernel that it shall shut down.
> Therefore "ctrl_alt_del();" is used which sends SIGINT to the init process.
>
> Thus from my perspective nmi.c is the one for the description of SIGPWR
> and the description is fine.
>
> If those information is not the desired one, please ask again with a few
> more hints about which ctrl-alt-del reference you mean.
Thank you for providing that background. I didn't know how well the
terminology aligns with kernel sources. I just thought it was a bit odd
that this very PC-ish terminology showed up in this particular context.
Thanks,
Florian
* DJ Delorie:
> index 2012980efe..a9cf34c459 100644
> --- a/manual/signal.texi
> +++ b/manual/signal.texi
> @@ -427,9 +427,18 @@ failure to properly emulate them.
>
> @deftypevr Macro int SIGSYS
> @standards{Unix, signal.h}
> -Bad system call; that is to say, the instruction to trap to the
> -operating system was executed, but the code number for the system call
> -to perform was invalid.
> +System call event. This signal may be generated by a valid system
> +call which requested an invalid sub-function, and also by the SECCOMP
> +filter when it filters a system call.
Suggest: when it filters [or traps] a system call
See SECCOMP_RET_TRAP.
With Stefan's last comments, I consider my ctrl-alt-del questions
resolves.
So consider making that seccomp adjustment, and then:
Reviewed-by: Florian Weimer <fweimer@redhat.com>
Thanks,
Florian
Florian Weimer <fweimer@redhat.com> writes:
> Suggest: when it filters [or traps] a system call
Changed.
> Reviewed-by: Florian Weimer <fweimer@redhat.com>
Thanks! Pushed.
@@ -427,9 +427,18 @@ failure to properly emulate them.
@deftypevr Macro int SIGSYS
@standards{Unix, signal.h}
-Bad system call; that is to say, the instruction to trap to the
-operating system was executed, but the code number for the system call
-to perform was invalid.
+System call event. This signal may be generated by a valid system
+call which requested an invalid sub-function, and also by the SECCOMP
+filter when it filters a system call.
+
+If the system call itself is invalid or unsupported by the kernel, the
+call will not raise this signal, but will return @code{ENOSYS}.
+@end deftypevr
+
+@deftypevr Macro int SIGSTKFLT
+Coprocessor stack fault. Obsolete, no longer generated. This signal
+may be used by applications in much the way @code{SIGUSR1} and
+@code{SIGUSR2} are.
@end deftypevr
@node Termination Signals
@@ -752,12 +761,11 @@ that isn't connected. @xref{Sending Data}.
@deftypevr Macro int SIGLOST
@standards{GNU, signal.h}
@cindex lost resource signal
-Resource lost. This signal is generated when you have an advisory lock
-on an NFS file, and the NFS server reboots and forgets about your lock.
-
-On @gnuhurdsystems{}, @code{SIGLOST} is generated when any server program
-dies unexpectedly. It is usually fine to ignore the signal; whatever
-call was made to the server that died just returns an error.
+Resource lost. On @gnuhurdsystems{}, @code{SIGLOST} is generated when
+any server program dies unexpectedly. It is usually fine to ignore
+the signal; whatever call was made to the server that died just
+returns an error. This signal's original purpose of signalling a lost
+NFS lock is obsolete.
@end deftypevr
@deftypevr Macro int SIGXCPU
@@ -817,6 +825,17 @@ to print some status information about the system and what the process
is doing. Otherwise the default is to do nothing.
@end deftypevr
+@deftypevr Macro int SIGPWR
+@cindex power event signal
+Power lost or restored. On s390x Linux systems, this signal is
+generated when a machine check warning is issued, and is sent to the
+process designated to receive ctrl-alt-del notifications. Otherwise,
+it is up to userspace applications to generate this signal and manage
+notifications as to the type of power event that happened.
+
+The default action is to terminate the process.
+@end deftypevr
+
@node Signal Messages
@subsection Signal Messages
@cindex signal messages