s390: fix endless loop in do_signal

PATCH Superseded Sumanth Korikkar 3 participants 6 messages Feb 15, 2023

Subsystems (2)

Stable branch s390

lore

Share & tools

lore

Sumanth Korikkar

author

2023-02-15 12:06 UTC #0 lore raw

cover s390: fix endless loop in do_signal

Hi,

This patch fixes the issue for s390 stable kernel starting 5.10.162. The issue was specifically seen after stable version 5.10.162:
Following commits can trigger it:
1. stable commit id - 788d0824269b ("io_uring: import 5.15-stable io_uring") can trigger this problem.
2. upstream commit id - 75309018a24d ("s390: add support for TIF_NOTIFY_SIGNAL")

Problem:
qemu and user processes could stall when TIF_NOTIFY_SIGNAL is set from io_uring work.

Affected users:
The issue was first raised by the debian team, where the s390 bullseye build systems are affected.

Upstream commit Id:
* The attached patch has no upstream commit. However, the stable kernel 5.10.162+ uses upstream commit id - 75309018a24d ("s390: add support for TIF_NOTIFY_SIGNAL"), which would need this fix
* Starting from v5.12, there are s390 generic entry commits 56e62a737028 ("s390: convert to generic entry") and its relevant fixes, which are recommended and should address these problems.

Kernel version to be applied:
stable kernel 5.10.162+

Thanks.
Sumanth

Sumanth Korikkar (1):
s390/signal: fix endless loop in do_signal

 arch/s390/kernel/signal.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Signature · 1 line

2.37.2

Sumanth Korikkar

author

2023-02-15 12:06 UTC #1 lore raw

PATCH 1/1 s390/signal: fix endless loop in do_signal

No upstream commit exists.

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 [email protected] # 5.10.162

Acked-by Heiko Carstens <[email protected]>

Acked-by Sven Schnelle <[email protected]>

Signed-off-by Sumanth Korikkar <[email protected]>

---
 arch/s390/kernel/signal.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

arch/s390/kernel/signal.c +1 -1

index b27b6c1f058d..9e900a8977bd 100644
@@ -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;

Signature · 1 line

2.37.2

Greg KH

maintainer

2023-02-15 13:22 UTC #2 lore raw

Re: [PATCH 1/1] s390/signal: fix endless loop in do_signal

Quoted 1 line · Sumanth Korikkar

No upstream commit exists.

Why not? Please explain how this was fixed in Linus's tree and why we can't take the same change here as well.

thanks,

greg k-h

Greg KH

maintainer

2023-02-15 13:23 UTC #3 lore raw

In reply to Sumanth Korikkar

Quoted 18 lines · Sumanth Korikkar

Hi,
This patch fixes the issue for s390 stable kernel starting 5.10.162. The issue was specifically seen after stable version 5.10.162:
Following commits can trigger it:
1. stable commit id - 788d0824269b ("io_uring: import 5.15-stable io_uring") can trigger this problem.
2. upstream commit id - 75309018a24d ("s390: add support for TIF_NOTIFY_SIGNAL")
Problem:
qemu and user processes could stall when TIF_NOTIFY_SIGNAL is set from io_uring work.
Affected users:
The issue was first raised by the debian team, where the s390 bullseye build systems are affected.

Quoted 7 lines

Upstream commit Id:
* The attached patch has no upstream commit. However, the stable kernel 5.10.162+ uses upstream commit id - 75309018a24d ("s390: add support for TIF_NOTIFY_SIGNAL"), which would need this fix
* Starting from v5.12, there are s390 generic entry commits 56e62a737028 ("s390: convert to generic entry") and its relevant fixes, which are recommended and should address these problems.

I'm sorry, but I do not understand. What exact commits should be added to the 5.10.y tree to resolve this?

thanks,

greg k-h

Heiko Carstens

maintainer

2023-02-15 13:35 UTC #4 lore raw

Quoted 27 lines · Greg KH

Quoted 18 lines · Sumanth Korikkar
Hi,
This patch fixes the issue for s390 stable kernel starting 5.10.162. The issue was specifically seen after stable version 5.10.162:
Following commits can trigger it:
1. stable commit id - 788d0824269b ("io_uring: import 5.15-stable io_uring") can trigger this problem.
2. upstream commit id - 75309018a24d ("s390: add support for TIF_NOTIFY_SIGNAL")
Problem:
qemu and user processes could stall when TIF_NOTIFY_SIGNAL is set from io_uring work.
Affected users:
The issue was first raised by the debian team, where the s390 bullseye build systems are affected.
Quoted 7 lines
Upstream commit Id:
* The attached patch has no upstream commit. However, the stable kernel 5.10.162+ uses upstream commit id - 75309018a24d ("s390: add support for TIF_NOTIFY_SIGNAL"), which would need this fix
* Starting from v5.12, there are s390 generic entry commits 56e62a737028 ("s390: convert to generic entry") and its relevant fixes, which are recommended and should address these problems.

Quoted 2 lines

I'm sorry, but I do not understand. What exact commits should be added to the 5.10.y tree to resolve this?

Only the patch sent by Sumanth as reply to this cover letter should be added to the 5.10.y tree.

The problem that is 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 that.

I doesn't look sane to backport commit 56e62a737028 ("s390: convert to generic entry"), since that is huge and came with a lot of bugs, where I'm not sure if all bug fixes had Fixes tags.

So the one-liner provided by Sumanth seems to be the best way to address this bug.

Greg KH

maintainer

2023-02-15 13:49 UTC #5 lore raw

Quoted 31 lines · Heiko Carstens

Quoted 27 lines · Greg KH
Quoted 18 lines · Sumanth Korikkar
Hi,
This patch fixes the issue for s390 stable kernel starting 5.10.162. The issue was specifically seen after stable version 5.10.162:
Following commits can trigger it:
1. stable commit id - 788d0824269b ("io_uring: import 5.15-stable io_uring") can trigger this problem.
2. upstream commit id - 75309018a24d ("s390: add support for TIF_NOTIFY_SIGNAL")
Problem:
qemu and user processes could stall when TIF_NOTIFY_SIGNAL is set from io_uring work.
Affected users:
The issue was first raised by the debian team, where the s390 bullseye build systems are affected.
Quoted 7 lines
Upstream commit Id:
* The attached patch has no upstream commit. However, the stable kernel 5.10.162+ uses upstream commit id - 75309018a24d ("s390: add support for TIF_NOTIFY_SIGNAL"), which would need this fix
* Starting from v5.12, there are s390 generic entry commits 56e62a737028 ("s390: convert to generic entry") and its relevant fixes, which are recommended and should address these problems.
Quoted 2 lines
I'm sorry, but I do not understand. What exact commits should be added to the 5.10.y tree to resolve this?

Quoted 8 lines

Only the patch sent by Sumanth as reply to this cover letter should be added to the 5.10.y tree.
The problem that is 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 that.

Ok, then please say that in the changelog text.

thanks,

greg k-h