| Message ID | 20220805061810.10824-1-ms@dev.tdt.de (mailing list archive) |
|---|---|
| State | Accepted |
| Commit | 944e594cfa84ec552831489c244e02589d826b11 |
| Delegated to: | Netdev Maintainers |
| Headers | show |
| Series | [net] net/x25: fix call timeouts in blocking connects | expand |
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!
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);
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(+)