Re: [PATCH v3 4/7] linux/signal.h: Ignore SIGINFO by default in new tasks
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date: 2020-04-30 07:19:57
Also in:
linux-serial, lkml
On Thu, Apr 30, 2020 at 09:14:37AM +0200, Christian Brauner 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?
That's my main hesitation for taking this patchset.
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.
That's a good reason to not do this :( greg k-h