Received: by 2002:a17:90a:9307:0:0:0:0 with SMTP id p7csp3963964pjo; Tue, 3 Mar 2020 10:11:00 -0800 (PST) X-Google-Smtp-Source: ADFU+vs+U7hdlVibpIYJ59aaYcsB8DT6uYCtqTt7UgA8m3TgQMVT5i0FW/Yc+Y1EAKApgfVnCDIR X-Received: by 2002:a05:6808:910:: with SMTP id w16mr1128128oih.30.1583259060646; Tue, 03 Mar 2020 10:11:00 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1583259060; cv=none; d=google.com; s=arc-20160816; b=0VzKN8eKxYlnZQ/w8q4fz/CC4NLKwhaKhc4W40jsk1ddrWH062bjyGlUZ7ByQ3UBdx tKGtfMvIsn0ORWrCfQLH0lN7HJNoGCZ4/UDqi+s+b7SPgHLu+q/ZmrnD/aQyen7CMu0P ehLrryz3M5oTmrs+vDwiRnM3vga4hMqU+zqhAZUCykmqenmw87xXPPZCVgOH3wTSz6Zv +DqvYTR2kgRd9xXxZdFUG7tXknI9iP8qgZriWYoH/GKLpdt1fU3clUJIHe+CeNrKwal4 a7zbA/LX+EzLwPO3/gDQd0sMBnjT2sU/zouHgq9Iw5uOa03+2ZhBlqtyqSvgiWCQnVnx GNxg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:message-id:date:subject:cc:to :from:dkim-signature; bh=9XxcBl7+CStPh87CkJHN44LgMSD+X+/w3KEOYXDsgiw=; b=GNvqF1WeCm/EeYjSDxqWXGpznbjfKKN+g+0ry20d81amal6RBHSSzIXdczjQMf/y/n fU5BPXjc00Gr/UqJyn1ThGtRclf8eTBlnjpf3qB6RuDDQem+pf5H1hfxBXpkqHeEe4Ri FBRKNeCXdM8T8aN3066mWuAKCDrq7P72/I3Q1Ba/9Cnf8rBK3ZlrkJHtY9l2jiS54g5q U7C/aK2zYBzkqE5AqN6SGoylluJJjBnnPRBXgMhJJIUsIbdXXju+/YhqTqsDNgCSkFAT a5S+MJmtRP+sjIVJAHJ3Epu8aDexPe6KBm1guE2edGfH/1UvL/qTFja2QHow+mbggUBC EwEg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=vKfLap2M; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id i18si956895otk.245.2020.03.03.10.10.48; Tue, 03 Mar 2020 10:11:00 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=vKfLap2M; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1733276AbgCCSKI (ORCPT + 99 others); Tue, 3 Mar 2020 13:10:08 -0500 Received: from mail.kernel.org ([198.145.29.99]:59412 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1731976AbgCCRvW (ORCPT ); Tue, 3 Mar 2020 12:51:22 -0500 Received: from localhost (83-86-89-107.cable.dynamic.v4.ziggo.nl [83.86.89.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 03AE020728; Tue, 3 Mar 2020 17:51:20 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1583257881; bh=m7OLOWwF4hX4DtMx03rja13wZd/rZ41dd7u6ifR3LeI=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=vKfLap2MlfCLWJ9V2C55gRL573P9VSnVwi0Qv4d5tbIwCbX7aG4p58wsLol3CBIM9 gD6j8KROToUKIrzvwSUB5TttFa9YWaEgm94T9veJ24V8uQBDZ3Y2qCS+ii+bwNxOBH AW0aKZ6TNMghkeUXXRUE5zvytByfzTFX3JKUcoLU= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Ying Xue , Jon Maloy , Tuong Lien , "David S. Miller" Subject: [PATCH 5.5 136/176] tipc: fix successful connect() but timed out Date: Tue, 3 Mar 2020 18:43:20 +0100 Message-Id: <20200303174320.493470489@linuxfoundation.org> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20200303174304.593872177@linuxfoundation.org> References: <20200303174304.593872177@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Tuong Lien commit 5391a87751a164b3194864126f3b016038abc9fe upstream. In commit 9546a0b7ce00 ("tipc: fix wrong connect() return code"), we fixed the issue with the 'connect()' that returns zero even though the connecting has failed by waiting for the connection to be 'ESTABLISHED' really. However, the approach has one drawback in conjunction with our 'lightweight' connection setup mechanism that the following scenario can happen: (server) (client) +- accept()| | wait_for_conn() | | |connect() -------+ | |<-------[SYN]---------| > sleeping | | *CONNECTING | |--------->*ESTABLISHED | | |--------[ACK]-------->*ESTABLISHED > wakeup() send()|--------[DATA]------->|\ > wakeup() send()|--------[DATA]------->| | > wakeup() . . . . |-> recvq . . . . . | . send()|--------[DATA]------->|/ > wakeup() close()|--------[FIN]-------->*DISCONNECTING | *DISCONNECTING | | | ~~~~~~~~~~~~~~~~~~> schedule() | wait again . . | ETIMEDOUT Upon the receipt of the server 'ACK', the client becomes 'ESTABLISHED' and the 'wait_for_conn()' process is woken up but not run. Meanwhile, the server starts to send a number of data following by a 'close()' shortly without waiting any response from the client, which then forces the client socket to be 'DISCONNECTING' immediately. When the wait process is switched to be running, it continues to wait until the timer expires because of the unexpected socket state. The client 'connect()' will finally get ‘-ETIMEDOUT’ and force to release the socket whereas there remains the messages in its receive queue. Obviously the issue would not happen if the server had some delay prior to its 'close()' (or the number of 'DATA' messages is large enough), but any kind of delay would make the connection setup/shutdown "heavy". We solve this by simply allowing the 'connect()' returns zero in this particular case. The socket is already 'DISCONNECTING', so any further write will get '-EPIPE' but the socket is still able to read the messages existing in its receive queue. Note: This solution doesn't break the previous one as it deals with a different situation that the socket state is 'DISCONNECTING' but has no error (i.e. sk->sk_err = 0). Fixes: 9546a0b7ce00 ("tipc: fix wrong connect() return code") Acked-by: Ying Xue Acked-by: Jon Maloy Signed-off-by: Tuong Lien Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman --- net/tipc/socket.c | 2 ++ 1 file changed, 2 insertions(+) --- a/net/tipc/socket.c +++ b/net/tipc/socket.c @@ -2441,6 +2441,8 @@ static int tipc_wait_for_connect(struct return -ETIMEDOUT; if (signal_pending(current)) return sock_intr_errno(*timeo_p); + if (sk->sk_state == TIPC_DISCONNECTING) + break; add_wait_queue(sk_sleep(sk), &wait); done = sk_wait_event(sk, timeo_p, tipc_sk_connected(sk),