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

[Sumanth Korikkar]

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: sta...@vger.kernel.org # 5.10.162
Acked-by: Heiko Carstens <h...@linux.ibm.com>
Acked-by: Sven Schnelle <sv...@linux.ibm.com>
Signed-off-by: Sumanth Korikkar <suma...@linux.ibm.com>
---
arch/s390/kernel/signal.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/s390/kernel/signal.c b/arch/s390/kernel/signal.c
index b27b6c1f058d..9e900a8977bd 100644
--- a/arch/s390/kernel/signal.c
+++ b/arch/s390/kernel/signal.c
@@ -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;
--
2.37.2

[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.

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(-)

--
2.37.2

[Greg KH]

On Wed, Feb 15, 2023 at 01:04:12PM +0100, Sumanth Korikkar wrote:
> 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.

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

[Greg KH]

On Wed, Feb 15, 2023 at 01:04:13PM +0100, Sumanth Korikkar wrote:
> 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

[Heiko Carstens]

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]

Ok, then please say that in the changelog text.

thanks,

greg k-h

[Sumanth Korikkar]

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 75309018a24d ("s390: add support for TIF_NOTIFY_SIGNAL")', 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: sta...@vger.kernel.org # 5.10.162
Acked-by: Heiko Carstens <h...@linux.ibm.com>
Acked-by: Sven Schnelle <sv...@linux.ibm.com>
Signed-off-by: Sumanth Korikkar <suma...@linux.ibm.com>
---

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

[Sumanth Korikkar]

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: sta...@vger.kernel.org # 5.10.162
Acked-by: Heiko Carstens <h...@linux.ibm.com>
Acked-by: Sven Schnelle <sv...@linux.ibm.com>
Signed-off-by: Sumanth Korikkar <suma...@linux.ibm.com>
---

v2->v3:
Correct changelog.

v1->v2:
Add the changelog.

[gre...@linuxfoundation.org]

This is a note to let you know that I've just added the patch titled

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

to the 5.10-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary

The filename of the patch is:
s390-signal-fix-endless-loop-in-do_signal.patch
and it can be found in the queue-5.10 subdirectory.

If you, or anyone else, feels it should not be added to the stable tree,
please let <sta...@vger.kernel.org> know about it.


>From suma...@linux.ibm.com Fri Feb 17 15:04:16 2023
From: Sumanth Korikkar <suma...@linux.ibm.com>
Date: Wed, 15 Feb 2023 15:13:24 +0100
Subject: [PATCH v2 1/1] s390/signal: fix endless loop in do_signal
To: sta...@vger.kernel.org, gre...@linuxfoundation.org, debia...@lists.debian.org, debian...@lists.debian.org
Cc: sv...@linux.ibm.com, h...@linux.ibm.com, g...@linux.ibm.com, suma...@linux.ibm.com, Ulrich....@de.ibm.com, dipak...@ibm.com
Message-ID: <20230215141324.1...@linux.ibm.com>

From: Sumanth Korikkar <suma...@linux.ibm.com>

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: sta...@vger.kernel.org # 5.10.162
Acked-by: Heiko Carstens <h...@linux.ibm.com>
Acked-by: Sven Schnelle <sv...@linux.ibm.com>
Signed-off-by: Sumanth Korikkar <suma...@linux.ibm.com>

Signed-off-by: Greg Kroah-Hartman <gre...@linuxfoundation.org>

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

--- a/arch/s390/kernel/signal.c
+++ b/arch/s390/kernel/signal.c
@@ -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;

Patches currently in stable-queue which might be from suma...@linux.ibm.com are

queue-5.10/s390-signal-fix-endless-loop-in-do_signal.patch

[Greg KH]

On Wed, Feb 15, 2023 at 03:13:24PM +0100, Sumanth Korikkar wrote:
> 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 75309018a24d ("s390: add support for TIF_NOTIFY_SIGNAL")', 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: sta...@vger.kernel.org # 5.10.162
> Acked-by: Heiko Carstens <h...@linux.ibm.com>
> Acked-by: Sven Schnelle <sv...@linux.ibm.com>
> Signed-off-by: Sumanth Korikkar <suma...@linux.ibm.com>
> ---
> arch/s390/kernel/signal.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)

Now queued up, thanks.

greg k-h