On 2020-04-30, Christian Brauner [off-list ref] wrote:

On Thu, Apr 30, 2020 at 08:53:56AM +0200, Jiri Slaby wrote:

quoted

On 30. 04. 20, 8:42, Arseny Maslennikov wrote:

quoted

This matches the behaviour of other Unix-like systems that have SIGINFO
and causes less harm to processes that do not install handlers for this
signal, making the keyboard status character non-fatal for them.

This is implemented with the assumption that SIGINFO is defined
to be equivalent to SIGPWR; still, there is no reason for PWR to
result in termination of the signal recipient anyway — it does not
indicate there is a fatal problem with the recipient's execution
context (like e.g. FPE/ILL do), and we have TERM/KILL for explicit
termination requests.

To put it another way:
The only scenario where system behaviour actually changes is when the
signal recipient has default disposition for SIGPWR. If a process
chose to interpret a SIGPWR as an incentive to cleanly terminate, it
would supply its own handler — and this commit does not affect processes
with non-default handlers.

Signed-off-by: Arseny Maslennikov <redacted>
---
 include/linux/signal.h | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/include/linux/signal.h b/include/linux/signal.h
index 05bacd2ab..dc31da8fc 100644
--- a/include/linux/signal.h
+++ b/include/linux/signal.h

@@ -369,7 +369,7 @@ extern bool unhandled_signal(struct task_struct *tsk, int sig);
  *	|  SIGSYS/SIGUNUSED  |	coredump 	|
  *	|  SIGSTKFLT         |	terminate	|
  *	|  SIGWINCH          |	ignore   	|
- *	|  SIGPWR            |	terminate	|
+ *	|  SIGPWR            |	ignore   	|

You need to update signal.7 too:
https://git.kernel.org/pub/scm/docs/man-pages/man-pages.git/tree/man7/signal.7#n285

(I fail this whole thread via b4 and it appears that a bunch of messages
are missing on lore. Might just be delay though.)

How this is this not going to break userspace? Just for a start,
SIGPWR (for better or worse) was used for a long time by some
sandboxing/container runtimes to shutdown a process and still is.

To play Devil's advocate -- pid1 has also always had a default-ignore
signal mask (which included SIGPWR), so any pid1 that obeyed SIGPWR
already had a non-default signal mask (and thus wouldn't be affected by
this patch).

But I do agree that this seems like a strange change to make (SIGPWR
seems like a signal you don't want to ignore by default). Unfortunately
the fact that it appears to always be equal to SIGINFO means that while
SIGINFO (to me at least) seems like it should be a no-op, the necessary
SIGPWR change makes it harder to justify IMHO.

-- 
Aleksa Sarai
Senior Software Engineer (Containers)
SUSE Linux GmbH
<https://www.cyphar.com/>