Received: by 2002:a05:6602:18e:0:0:0:0 with SMTP id m14csp3506312ioo; Wed, 25 May 2022 02:04:15 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyeolqhJNJ2ITOoeSgpQv9gGOV1GhRlc/PPZeTc7nrP3nLCKFOcbl3mNnbp3sjxRlPwlTVv X-Received: by 2002:a17:907:6e09:b0:6ff:4b5:4a8f with SMTP id sd9-20020a1709076e0900b006ff04b54a8fmr6752974ejc.139.1653469455013; Wed, 25 May 2022 02:04:15 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1653469455; cv=none; d=google.com; s=arc-20160816; b=RQgztmrizVRQWbgLwio3RltVSwOwEm/ej0dw8B9s/CnQ2FoZrR6U8np5aidiDfa/eg nZRHan/E13U0SKUEF6+Jv5mPhUz7Jm7SX/uAFlDR3IC/CFnmsuKCPoVsuogj5Oo1LE8Z DbT6nt/78ngQDCkUWpkRI1PYIMJ7L1fwrNOfuVxIjY/pgbna5iW2AmPZipHUMUN8vCZF 1wCUFuY2gX8yOH3ru2fFuedtT1nwrK0AapXabVh8ALjw9W0ry8vlUc2XodbwGxE3hsFe 4Uqc2awnLvW9hFfShoSx7/Vm48TOBTnDLnqRRDtiTE9iPwnI7s1WfhdhOjbxOieql2Ue edsQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=Yt7B0KucM2nqy+KyVy3N/Gqg5XShwOIM39x08j9SOA0=; b=Vg+uTP5010XC6RC3m1DxaOYjibo1Wk9nkta0wgNou9b5LYNLnsu+pNrqR08+spDa7x cxEEFQ5VN70fq7fiLS4d9iq5SQ6l1PuCF8+e4IZ0OT2vbr4WQ0QEgWIE4hHVgSRHyq/O /YuOOtwFq6TlROGWbp7btHIowwHdD/EdiS3pPUZQ0tWzknTO0ge/WITC/HlkVdCcu4Sx EmkSwHFryKzUmB2E0KSHYUdWEAHYm3bt6XztB1JBBgGZMKZRAN2nUUDdo9Cq4u4yuIgA WXOxPzlUV1QmWgPQd73U87qnR0Zgohtwu+AM0VTWRrY/YJuCFGS02fsMhYO+gD1lgb1E QGzQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@corp.netease.com header.s=s210401 header.b=RsFe2cG2; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=corp.netease.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id nd31-20020a170907629f00b006f4ceb7f5bcsi14806802ejc.74.2022.05.25.02.03.45; Wed, 25 May 2022 02:04:15 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@corp.netease.com header.s=s210401 header.b=RsFe2cG2; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=corp.netease.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237500AbiEXM5i (ORCPT + 99 others); Tue, 24 May 2022 08:57:38 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:40478 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232013AbiEXM5h (ORCPT ); Tue, 24 May 2022 08:57:37 -0400 Received: from corp-front09-corp.i.nease.net (corp-front09-corp.i.nease.net [59.111.134.159]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 8809027FF6; Tue, 24 May 2022 05:57:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=corp.netease.com; s=s210401; h=Received:From:To:Cc:Subject: Date:Message-Id:In-Reply-To:References:MIME-Version:Content-Type: Content-Transfer-Encoding; bh=Yt7B0KucM2nqy+KyVy3N/Gqg5XShwOIM39 x08j9SOA0=; b=RsFe2cG2ulHWNUz/b9CMyHQi+1UkeiICypCPbvQ5kahiXcpymN tpwjeSfpnFI31x/ENuttA9vJlPRnr62RS97/srA0cnPxGaeXqoXBB0QU6FRx0xkD lef2CnUFJR9zCJVVTNQejVhX7hslIiZeUlt18us8WTOe25XcdFo6zGi48= Received: from pubt1-k8s74.yq.163.org (unknown [115.238.122.38]) by corp-front09-corp.i.nease.net (Coremail) with SMTP id nxDICgDn6V411oxiVBZhAA--.16490S2; Tue, 24 May 2022 20:57:26 +0800 (HKT) From: liuyacan@corp.netease.com To: kgraul@linux.ibm.com Cc: davem@davemloft.net, guangguan.wang@linux.alibaba.com, kuba@kernel.org, linux-kernel@vger.kernel.org, linux-s390@vger.kernel.org, netdev@vger.kernel.org, pabeni@redhat.com Subject: Re: [PATCH net-next v2] net/smc: align the connect behaviour with TCP Date: Tue, 24 May 2022 20:57:25 +0800 Message-Id: <20220524125725.951315-1-liuyacan@corp.netease.com> X-Mailer: git-send-email 2.20.1 In-Reply-To: <26d43c65-1f23-5b83-6377-3327854387c4@linux.ibm.com> References: <26d43c65-1f23-5b83-6377-3327854387c4@linux.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-CM-TRANSID: nxDICgDn6V411oxiVBZhAA--.16490S2 X-Coremail-Antispam: 1UD129KBjvJXoWxCw1UWF1DGr45Zw4UAFyUGFg_yoWrXr1Upr yIka9akrWDJr13urnIv3WDCFsayws5JF45GryxWFy8CwnFvFnxJrZ7KrWj9a17ZFykGryU Zr48ZFZxKFZ8A37anT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUJGb7IF0VCFI7km07C26c804VAKzcIF0wAYjsxI4VWDJwAYFVCj jxCrM7AC8VAFwI0_Gr0_Xr1l1xkIjI8I6I8E6xAIw20EY4v20xvaj40_Wr0E3s1l1IIY67 AEw4v_Jr0_Jr4l8cAvFVAK0II2c7xJM28CjxkF64kEwVA0rcxSw2x7M28EF7xvwVC0I7IY x2IY67AKxVWDJVCq3wA2z4x0Y4vE2Ix0cI8IcVCY1x0267AKxVWxJr0_GcWl84ACjcxK6I 8E87Iv67AKxVW0oVCq3wA2z4x0Y4vEx4A2jsIEc7CjxVAFwI0_GcCE3s1ln4vE1TuYJxuj qTIEc-sFP3VYkVW5Jr1DJw4UKVWUGwAawVACjsI_Ar4v6c8GOVW06r1DJrWUAwAawVACjs I_Ar4v6c8GOVWY6r1DJrWUAwAawVCFI7vE04vSzxk24VAqrcv_Gr1UXr18M2vj6xkI62vS 6c8GOVWUtr1rJFyle2I262IYc4CY6c8Ij28IcVAaY2xG8wAqjxCE34x0Y48IcwAqx4xG64 xvF2IEw4CE5I8CrVC2j2WlYx0E2Ix0cI8IcVAFwI0_Jr0_Jr4lYx0Ex4A2jsIE14v26r1j 6r4UMcvjeVCFs4IE7xkEbVWUJVW8JwACjcxG0xvY0x0EwIxGrwAKzVCY07xG64k0F24l7I 0Y64k_MxkI7II2jI8vz4vEwIxGrwCF04k20xvY0x0EwIxGrwCF72vEw2IIxxk0rwCFx2Iq xVCFs4IE7xkEbVWUJVW8JwCFI7vE0wC20s026c02F40E14v26r1j6r18MI8I3I0E7480Y4 vE14v26r106r1rMI8E67AF67kF1VAFwI0_Jw0_GFylIxkGc2Ij64vIr41lIxAIcVC0I7IY x2IY67AKxVWUJVWUCwCI42IY6xIIjxv20xvEc7CjxVAFwI0_Jr0_Gr1lIxAIcVCF04k26c xKx2IYs7xG6r1j6r1xMIIF0xvEx4A2jsIE14v26r1j6r4UMIIF0xvEx4A2jsIEc7CjxVAF wI0_Gr0_Gr1UYxBIdaVFxhVjvjDU0xZFpf9x07j6wZ7UUUUU= X-CM-SenderInfo: 5olx5txfdqquhrush05hwht23hof0z/1tbiBQAQCVt761lFGAAFsW X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > > > > > > On 2022/5/23 20:24, Karsten Graul wrote: > >> On 13/05/2022 04:24, Guangguan Wang wrote: > >>> Connect with O_NONBLOCK will not be completed immediately > >>> and returns -EINPROGRESS. It is possible to use selector/poll > >>> for completion by selecting the socket for writing. After select > >>> indicates writability, a second connect function call will return > >>> 0 to indicate connected successfully as TCP does, but smc returns > >>> -EISCONN. Use socket state for smc to indicate connect state, which > >>> can help smc aligning the connect behaviour with TCP. > >>> > >>> Signed-off-by: Guangguan Wang > >>> Acked-by: Karsten Graul > >>> --- > >>> net/smc/af_smc.c | 50 ++++++++++++++++++++++++++++++++++++++++++++---- > >>> 1 file changed, 46 insertions(+), 4 deletions(-) > >>> > >>> diff --git a/net/smc/af_smc.c b/net/smc/af_smc.c > >>> index fce16b9d6e1a..5f70642a8044 100644 > >>> --- a/net/smc/af_smc.c > >>> +++ b/net/smc/af_smc.c > >>> @@ -1544,9 +1544,29 @@ static int smc_connect(struct socket *sock, struct sockaddr *addr, > >>> goto out_err; > >>> > >>> lock_sock(sk); > >>> + switch (sock->state) { > >>> + default: > >>> + rc = -EINVAL; > >>> + goto out; > >>> + case SS_CONNECTED: > >>> + rc = sk->sk_state == SMC_ACTIVE ? -EISCONN : -EINVAL; > >>> + goto out; > >>> + case SS_CONNECTING: > >>> + if (sk->sk_state == SMC_ACTIVE) > >>> + goto connected; > >> > >> I stumbled over this when thinking about the fallback processing. If for whatever reason > >> fallback==true during smc_connect(), the "if (smc->use_fallback)" below would set sock->state > >> to e.g. SS_CONNECTED. But in the fallback case sk_state keeps SMC_INIT. So during the next call > >> the SS_CONNECTING case above would break because sk_state in NOT SMC_ACTIVE, and we would end > >> up calling kernel_connect() again. Which seems to be no problem when kernel_connect() returns > >> -EISCONN and we return this to the caller. But is this how it should work, or does it work by chance? > >> > > > > Since the sk_state keeps SMC_INIT and does not correctly indicate the state of clcsock, it should end > > up calling kernel_connect() again to get the actual connection state of clcsock. > > > > And I'm sorry there is a problem that if sock->state==SS_CONNECTED and sk_state==SMC_INIT, further call > > of smc_connect will return -EINVAL where -EISCONN is preferred. > > The steps to reproduce: > > 1)switch fallback before connect, such as setsockopt TCP_FASTOPEN > > 2)connect with noblocking and returns -EINPROGRESS. (sock->state changes to SS_CONNECTING) > > 3) end up calling connect with noblocking again and returns 0. (kernel_connect() returns 0 and sock->state changes to > > SS_CONNECTED but sk->sk_state stays SMC_INIT) > > 4) call connect again, maybe by mistake, will return -EINVAL, but -EISCONN is preferred. > > > > What do you think about if we synchronize the sk_state to SMC_ACTIVE instead of keeping SMC_INIT when clcsock > > connected successfully in fallback case described above. > > > > ... > > I start thinking that the fix in 86434744 introduced a problem. Before that fix a connect with > fallback always reached __smc_connect() and on top of that function in case of fallback > smc_connect_fallback() is called, which itself sets sk_state to SMC_ACTIVE. > > 86434744 removed that code path and I wonder what it actually fixed, because at this time the > fallback check in __smc_connect() was already present. > > Without that "goto out;" the state would be set correctly in smc_connect_fallback(), and the > socket close processing would work as expected. I think it is OK without that "goto out;". And I guess the purpose of "goto out;" is to avoid calling __smc_connect(), because it is impossible to establish an rdma channel at this time.