patches/kernel/0012-mm-suppress-mm-fault-logging-if-fatal-signal-already.patch

   1 From 0000000000000000000000000000000000000000 Mon Sep 17 00:00:00 2001
   2 From: Linus Torvalds <torvalds@linux-foundation.org>
   3 Date: Tue, 25 Jul 2023 09:38:32 -0700
   4 Subject: [PATCH] mm: suppress mm fault logging if fatal signal already pending
   5
   6 Commit eda0047296a1 ("mm: make the page fault mmap locking killable")
   7 intentionally made it much easier to trigger the "page fault fails
   8 because a fatal signal is pending" situation, by having the mmap locking
   9 fail early in that case.
  10
  11 We have long aborted page faults in other fatal cases when the actual IO
  12 for a page is interrupted by SIGKILL - which is particularly useful for
  13 the traditional case of NFS hanging due to network issues, but local
  14 filesystems could cause it too if you happened to get the SIGKILL while
  15 waiting for a page to be faulted in (eg lock_folio_maybe_drop_mmap()).
  16
  17 So aborting the page fault wasn't a new condition - but it now triggers
  18 earlier, before we even get to 'handle_mm_fault()'.  And as a result the
  19 error doesn't go through our 'fault_signal_pending()' logic, and doesn't
  20 get filtered away there.
  21
  22 Normally you'd never even notice, because if a fatal signal is pending,
  23 the new SIGSEGV we send ends up being ignored anyway.
  24
  25 But it turns out that there is one very noticeable exception: if you
  26 enable 'show_unhandled_signals', the aborted page fault will be logged
  27 in the kernel messages, and you'll get a scary line looking something
  28 like this in your logs:
  29
  30   pverados[2183248]: segfault at 55e5a00f9ae0 ip 000055e5a00f9ae0 sp 00007ffc0720bea8 error 14 in perl[55e5a00d4000+195000] likely on CPU 10 (core 4, socket 0)
  31
  32 which is rather misleading.  It's not really a segfault at all, it's
  33 just "the thread was killed before the page fault completed, so we
  34 aborted the page fault".
  35
  36 Fix this by just making it clear that a pending fatal signal means that
  37 any new signal coming in after that is implicitly handled.  This will
  38 avoid the misleading logging, since now the signal isn't 'unhandled' any
  39 more.
  40
  41 Reported-and-tested-by: Fiona Ebner <f.ebner@proxmox.com>
  42 Tested-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
  43 Link: https://lore.kernel.org/lkml/8d063a26-43f5-0bb7-3203-c6a04dc159f8@proxmox.com/
  44 Acked-by: Oleg Nesterov <oleg@redhat.com>
  45 Fixes: eda0047296a1 ("mm: make the page fault mmap locking killable")
  46 Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
  47 (cherry-picked from commit 5f0bc0b042fc77ff70e14c790abdec960cde4ec1)
  48 Signed-off-by: Fiona Ebner <f.ebner@proxmox.com>
  49 ---
  50  kernel/signal.c | 4 ++++
  51  1 file changed, 4 insertions(+)
  52
  53 diff --git a/kernel/signal.c b/kernel/signal.c
  54 index ae26da61c4d9..060f834e9c1a 100644
  55 --- a/kernel/signal.c
  56 +++ b/kernel/signal.c
  57 @@ -561,6 +561,10 @@ bool unhandled_signal(struct task_struct *tsk, int sig)
  58         if (handler != SIG_IGN && handler != SIG_DFL)
  59                 return false;
  60
  61 +       /* If dying, we handle all new signals by ignoring them */
  62 +       if (fatal_signal_pending(tsk))
  63 +               return false;
  64 +
  65         /* if ptraced, let the tracer determine */
  66         return !tsk->ptrace;
  67  }