]> git.ipfire.org Git - thirdparty/kernel/stable.git/commitdiff
s390/signal: fix endless loop in do_signal
authorSumanth Korikkar <sumanthk@linux.ibm.com>
Wed, 15 Feb 2023 14:13:24 +0000 (15:13 +0100)
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Wed, 22 Feb 2023 11:55:54 +0000 (12:55 +0100)
No upstream commit exists: the problem addressed here is that 'commit
75309018a24d ("s390: add support for TIF_NOTIFY_SIGNAL")' was backported
to 5.10. This commit is broken, but nobody noticed upstream, since
shortly after s390 converted to generic entry with 'commit 56e62a737028
("s390: convert to generic entry")', which implicitly fixed the problem
outlined below.

Thread flag is set to TIF_NOTIFY_SIGNAL for io_uring work.  The io work
user or syscall calls do_signal when either one of the TIF_SIGPENDING or
TIF_NOTIFY_SIGNAL flag is set.  However, do_signal does consider only
TIF_SIGPENDING signal and ignores TIF_NOTIFY_SIGNAL condition.  This
means get_signal is never invoked  for TIF_NOTIFY_SIGNAL and hence the
flag is not cleared, which results in an endless do_signal loop.

Reference: 'commit 788d0824269b ("io_uring: import 5.15-stable io_uring")'
Fixes: 75309018a24d ("s390: add support for TIF_NOTIFY_SIGNAL")
Cc: stable@vger.kernel.org # 5.10.162
Acked-by: Heiko Carstens <hca@linux.ibm.com>
Acked-by: Sven Schnelle <svens@linux.ibm.com>
Signed-off-by: Sumanth Korikkar <sumanthk@linux.ibm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
arch/s390/kernel/signal.c

index b27b6c1f058d07e8175e85c640c243254e4efa84..9e900a8977bd2110f798439e1fc464c20a769e9b 100644 (file)
@@ -472,7 +472,7 @@ void do_signal(struct pt_regs *regs)
        current->thread.system_call =
                test_pt_regs_flag(regs, PIF_SYSCALL) ? regs->int_code : 0;
 
-       if (test_thread_flag(TIF_SIGPENDING) && get_signal(&ksig)) {
+       if (get_signal(&ksig)) {
                /* Whee!  Actually deliver the signal.  */
                if (current->thread.system_call) {
                        regs->int_code = current->thread.system_call;