Linux-man Archive on
 help / color / Atom feed
* [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
<> 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
older kernel.
 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
--- a/man2/sigaction.2
+++ b/man2/sigaction.2
@@ -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
+.I siginfo_t
+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
--- a/man7/signal.7
+++ b/man7/signal.7
@@ -796,16 +796,36 @@ Linux 2.4 and earlier:
 .BR nanosleep (2).
 POSIX.1, except as noted.
-.\" It must be a *very* long time since this was true:
-.\" .SH BUGS
-.\" .B SIGIO
-.\" and
-.\" 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:
+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
+.I int
+instruction with a forbidden argument
+(any number other than 3 or 128)
+causes delivery of
+even though
+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

Archives are clonable:
	git clone --mirror 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/ \
	public-inbox-index linux-man

Example config snippet for mirrors

Newsgroup available over NNTP:

AGPL code for this site: git clone