linux-x25.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH net] net/x25: fix call timeouts in blocking connects
@ 2022-08-05  6:18 Martin Schiller
  2022-08-09  4:00 ` patchwork-bot+netdevbpf
  0 siblings, 1 reply; 2+ messages in thread
From: Martin Schiller @ 2022-08-05  6:18 UTC (permalink / raw)
  To: davem, edumazet, kuba; +Cc: linux-x25, netdev, linux-kernel, Martin Schiller

When a userspace application starts a blocking connect(), a CALL REQUEST
is sent, the t21 timer is started and the connect is waiting in
x25_wait_for_connection_establishment(). If then for some reason the t21
timer expires before any reaction on the assigned logical channel (e.g.
CALL ACCEPT, CLEAR REQUEST), there is sent a CLEAR REQUEST and timer
t23 is started waiting for a CLEAR confirmation. If we now receive a
CLEAR CONFIRMATION from the peer, x25_disconnect() is called in
x25_state2_machine() with reason "0", which means "normal" call
clearing. This is ok, but the parameter "reason" is used as sk->sk_err
in x25_disconnect() and sock_error(sk) is evaluated in
x25_wait_for_connection_establishment() to check if the call is still
pending. As "0" is not rated as an error, the connect will stuck here
forever.

To fix this situation, also check if the sk->sk_state changed form
TCP_SYN_SENT to TCP_CLOSE in the meantime, which is also done by
x25_disconnect().

Signed-off-by: Martin Schiller <ms@dev.tdt.de>
---
 net/x25/af_x25.c | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/net/x25/af_x25.c b/net/x25/af_x25.c
index 6bc2ac8d8146..3b55502b2965 100644
--- a/net/x25/af_x25.c
+++ b/net/x25/af_x25.c
@@ -719,6 +719,11 @@ static int x25_wait_for_connection_establishment(struct sock *sk)
 			sk->sk_socket->state = SS_UNCONNECTED;
 			break;
 		}
+		rc = -ENOTCONN;
+		if (sk->sk_state == TCP_CLOSE) {
+			sk->sk_socket->state = SS_UNCONNECTED;
+			break;
+		}
 		rc = 0;
 		if (sk->sk_state != TCP_ESTABLISHED) {
 			release_sock(sk);
-- 
2.20.1


^ permalink raw reply related	[flat|nested] 2+ messages in thread

* Re: [PATCH net] net/x25: fix call timeouts in blocking connects
  2022-08-05  6:18 [PATCH net] net/x25: fix call timeouts in blocking connects Martin Schiller
@ 2022-08-09  4:00 ` patchwork-bot+netdevbpf
  0 siblings, 0 replies; 2+ messages in thread
From: patchwork-bot+netdevbpf @ 2022-08-09  4:00 UTC (permalink / raw)
  To: Martin Schiller; +Cc: davem, edumazet, kuba, linux-x25, netdev, linux-kernel

Hello:

This patch was applied to netdev/net.git (master)
by Jakub Kicinski <kuba@kernel.org>:

On Fri,  5 Aug 2022 08:18:10 +0200 you wrote:
> When a userspace application starts a blocking connect(), a CALL REQUEST
> is sent, the t21 timer is started and the connect is waiting in
> x25_wait_for_connection_establishment(). If then for some reason the t21
> timer expires before any reaction on the assigned logical channel (e.g.
> CALL ACCEPT, CLEAR REQUEST), there is sent a CLEAR REQUEST and timer
> t23 is started waiting for a CLEAR confirmation. If we now receive a
> CLEAR CONFIRMATION from the peer, x25_disconnect() is called in
> x25_state2_machine() with reason "0", which means "normal" call
> clearing. This is ok, but the parameter "reason" is used as sk->sk_err
> in x25_disconnect() and sock_error(sk) is evaluated in
> x25_wait_for_connection_establishment() to check if the call is still
> pending. As "0" is not rated as an error, the connect will stuck here
> forever.
> 
> [...]

Here is the summary with links:
  - [net] net/x25: fix call timeouts in blocking connects
    https://git.kernel.org/netdev/net/c/944e594cfa84

You are awesome, thank you!
-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html



^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2022-08-09  4:00 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-08-05  6:18 [PATCH net] net/x25: fix call timeouts in blocking connects Martin Schiller
2022-08-09  4:00 ` patchwork-bot+netdevbpf

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).