From 762b8cebe9fc4cc39f34808d2820a95ea13adfae Mon Sep 17 00:00:00 2001 From: Fiona Ebner Date: Fri, 25 Aug 2023 11:26:50 +0200 Subject: [PATCH] cherry-pick fix to surpress faulty segfault logging While there is no actual issue, users are still nervous about the faulty logging [0]. It might take a while until the fix comes in via upstream, so just pick it up manually. [0]: https://forum.proxmox.com/threads/130628/post-583864 Signed-off-by: Fiona Ebner --- ...ault-logging-if-fatal-signal-already.patch | 67 +++++++++++++++++++ 1 file changed, 67 insertions(+) create mode 100644 patches/kernel/0037-mm-suppress-mm-fault-logging-if-fatal-signal-already.patch diff --git a/patches/kernel/0037-mm-suppress-mm-fault-logging-if-fatal-signal-already.patch b/patches/kernel/0037-mm-suppress-mm-fault-logging-if-fatal-signal-already.patch new file mode 100644 index 0000000..769811b --- /dev/null +++ b/patches/kernel/0037-mm-suppress-mm-fault-logging-if-fatal-signal-already.patch @@ -0,0 +1,67 @@ +From 0000000000000000000000000000000000000000 Mon Sep 17 00:00:00 2001 +From: Linus Torvalds +Date: Tue, 25 Jul 2023 09:38:32 -0700 +Subject: [PATCH] mm: suppress mm fault logging if fatal signal already pending + +Commit eda0047296a1 ("mm: make the page fault mmap locking killable") +intentionally made it much easier to trigger the "page fault fails +because a fatal signal is pending" situation, by having the mmap locking +fail early in that case. + +We have long aborted page faults in other fatal cases when the actual IO +for a page is interrupted by SIGKILL - which is particularly useful for +the traditional case of NFS hanging due to network issues, but local +filesystems could cause it too if you happened to get the SIGKILL while +waiting for a page to be faulted in (eg lock_folio_maybe_drop_mmap()). + +So aborting the page fault wasn't a new condition - but it now triggers +earlier, before we even get to 'handle_mm_fault()'. And as a result the +error doesn't go through our 'fault_signal_pending()' logic, and doesn't +get filtered away there. + +Normally you'd never even notice, because if a fatal signal is pending, +the new SIGSEGV we send ends up being ignored anyway. + +But it turns out that there is one very noticeable exception: if you +enable 'show_unhandled_signals', the aborted page fault will be logged +in the kernel messages, and you'll get a scary line looking something +like this in your logs: + + pverados[2183248]: segfault at 55e5a00f9ae0 ip 000055e5a00f9ae0 sp 00007ffc0720bea8 error 14 in perl[55e5a00d4000+195000] likely on CPU 10 (core 4, socket 0) + +which is rather misleading. It's not really a segfault at all, it's +just "the thread was killed before the page fault completed, so we +aborted the page fault". + +Fix this by just making it clear that a pending fatal signal means that +any new signal coming in after that is implicitly handled. This will +avoid the misleading logging, since now the signal isn't 'unhandled' any +more. + +Reported-and-tested-by: Fiona Ebner +Tested-by: Thomas Lamprecht +Link: https://lore.kernel.org/lkml/8d063a26-43f5-0bb7-3203-c6a04dc159f8@proxmox.com/ +Acked-by: Oleg Nesterov +Fixes: eda0047296a1 ("mm: make the page fault mmap locking killable") +Signed-off-by: Linus Torvalds +(cherry-picked from commit 5f0bc0b042fc77ff70e14c790abdec960cde4ec1) +Signed-off-by: Fiona Ebner +--- + kernel/signal.c | 4 ++++ + 1 file changed, 4 insertions(+) + +diff --git a/kernel/signal.c b/kernel/signal.c +index ae26da61c4d9..060f834e9c1a 100644 +--- a/kernel/signal.c ++++ b/kernel/signal.c +@@ -561,6 +561,10 @@ bool unhandled_signal(struct task_struct *tsk, int sig) + if (handler != SIG_IGN && handler != SIG_DFL) + return false; + ++ /* If dying, we handle all new signals by ignoring them */ ++ if (fatal_signal_pending(tsk)) ++ return false; ++ + /* if ptraced, let the tracer determine */ + return !tsk->ptrace; + }