* [PATCH] Document kernel bugs in delivery of signals from CPU exceptions
@ 2019-12-23 17:31 Zack Weinberg
0 siblings, 0 replies; only message in thread
From: Zack Weinberg @ 2019-12-23 17:31 UTC (permalink / raw)
To: mtk.manpages; +Cc: linux-man
signal.7: Which signal is delivered in response to a CPU exception is
under-documented and does not always make sense. See
<https://bugzilla.kernel.org/show_bug.cgi?id=205831> for an example
where it doesn’t make sense; per the discussion there, this cannot be
changed because of backward compatibility concerns, so let’s instead
document the problem.
sigaction.2: For related reasons, the kernel doesn’t always fill in
all of the fields of the siginfo_t when delivering signals from CPU
exceptions. Document this as well. I imagine this one _could_ be
fixed, but the problem would still be relevant to anyone using an
man2/sigaction.2 | 8 ++++++++
man7/signal.7 | 40 ++++++++++++++++++++++++++++++----------
2 files changed, 38 insertions(+), 10 deletions(-)
diff --git a/man2/sigaction.2 b/man2/sigaction.2
index 8ee878672..10d1c4882 100644
@@ -1020,6 +1020,14 @@ handler.
See the relevant Linux kernel sources for details.
This use is obsolete now.
+When delivering a signal with a
+the kernel does not always provide meaningful values
+for all of the fields of the
+that are relevant for that signal.
In kernels up to and including 2.6.13, specifying
diff --git a/man7/signal.7 b/man7/signal.7
index d34e536f1..a9fe076fd 100644
@@ -796,16 +796,36 @@ Linux 2.4 and earlier:
.BR nanosleep (2).
.SH CONFORMING TO
POSIX.1, except as noted.
-.\" It must be a *very* long time since this was true:
-.\" .SH BUGS
-.\" .B SIGIO
-.\" .B SIGLOST
-.\" have the same value.
-.\" The latter is commented out in the kernel source, but
-.\" the build process of some software still thinks that
-.\" signal 29 is
-.\" .BR SIGLOST .
+There are six signals that can be delivered
+as a consequence of a hardware exception:
+.BR SIGBUS ,
+.BR SIGEMT ,
+.BR SIGFPE ,
+.BR SIGILL ,
+.BR SIGSEGV ,
+.BR SIGTRAP .
+Which of these signals is delivered,
+for any given hardware exception,
+is not documented and does not always make sense.
+For example, an invalid memory access that causes delivery of
+on one CPU architecture may cause delivery of
+on another architecture, or vice versa.
+For another example, using the x86
+instruction with a forbidden argument
+(any number other than 3 or 128)
+causes delivery of
+.BR SIGSEGV ,
+would make more sense,
+because of how the CPU reports the forbidden operation to the kernel.
For a discussion of async-signal-safe functions, see
.BR signal-safety (7).
^ permalink raw reply [flat|nested] only message in thread
only message in thread, back to index
Thread overview: (only message) (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-12-23 17:31 [PATCH] Document kernel bugs in delivery of signals from CPU exceptions Zack Weinberg
Linux-man Archive on lore.kernel.org
Archives are clonable:
git clone --mirror https://lore.kernel.org/linux-man/0 linux-man/git/0.git
# If you have public-inbox 1.1+ installed, you may
# initialize and index your mirror using the following commands:
public-inbox-init -V2 linux-man linux-man/ https://lore.kernel.org/linux-man \
Example config snippet for mirrors
Newsgroup available over NNTP:
AGPL code for this site: git clone https://public-inbox.org/public-inbox.git