From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from firstgate.proxmox.com (firstgate.proxmox.com [212.224.123.68]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by lists.proxmox.com (Postfix) with ESMTPS id DF3F29552 for ; Fri, 25 Aug 2023 11:26:59 +0200 (CEST) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id BF0B754A2 for ; Fri, 25 Aug 2023 11:26:59 +0200 (CEST) Received: from proxmox-new.maurer-it.com (proxmox-new.maurer-it.com [94.136.29.106]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by firstgate.proxmox.com (Proxmox) with ESMTPS for ; Fri, 25 Aug 2023 11:26:56 +0200 (CEST) Received: from proxmox-new.maurer-it.com (localhost.localdomain [127.0.0.1]) by proxmox-new.maurer-it.com (Proxmox) with ESMTP id 0676F43ED8 for ; Fri, 25 Aug 2023 11:26:55 +0200 (CEST) From: Fiona Ebner To: pve-devel@lists.proxmox.com Date: Fri, 25 Aug 2023 11:26:50 +0200 Message-Id: <20230825092650.922874-1-f.ebner@proxmox.com> X-Mailer: git-send-email 2.39.2 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-SPAM-LEVEL: Spam detection results: 0 AWL -0.573 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DMARC_MISSING 0.1 Missing DMARC policy HEXHASH_WORD 1 Multiple instances of word + hexadecimal hash KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record URIBL_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to URIBL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more information. [proxmox.com] Subject: [pve-devel] [PATCH kernel] cherry-pick fix to surpress faulty segfault logging X-BeenThere: pve-devel@lists.proxmox.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: Proxmox VE development discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Aug 2023 09:26:59 -0000 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; + } -- 2.39.2