Received: by 2002:a05:622a:251a:b0:39a:b4a2:e86 with SMTP id cm26csp316717qtb; Wed, 19 Oct 2022 02:44:20 -0700 (PDT) X-Google-Smtp-Source: AMsMyM5ZLLc2HqH8W/lDGf9pvxMqOnMS2nVa00chWFtcU38lcAkiVGdfRBcSr2Gx6jEZ2frGKAmI X-Received: by 2002:a17:907:5ce:b0:730:bae0:deb with SMTP id wg14-20020a17090705ce00b00730bae00debmr6104447ejb.181.1666172660701; Wed, 19 Oct 2022 02:44:20 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1666172660; cv=none; d=google.com; s=arc-20160816; b=Igo+NVTRBGZwbKdMyJhcvDmKAt2zjYnnFKfDYu2qX9LSQEpggAvW8ytEfo3oFc9PEA 5hmkXghIjVVl0geEtShk4Jv5AagZag0Ivu0jPfJ0XDSxbDhL3BiZW4XXK48jarHWQtRn 9xf84t0sv3EKIH+x9vyVlVesJFpEO8q0jGnZdUfe4yq+3XwVh9pUtdKLVeRP+YphTEkb LWlGElbPY7NDP5NXBQ/ts+nfNUJzUaDbhOjY0rnOMEB/3/cow19/Ltm8EWsgWRpSuJqG mQTnFmf5hOH04t639+RQ4eEe3Lsg3lH4phxBXMvNZlQaHlFLdsdf7qV4NO2Gv0RMcKHg MZyQ== 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 :user-agent:references:in-reply-to:message-id:date:subject:cc:to :from:dkim-signature; bh=yDzZDLBfeQwxQKhsiXI9kjlEHRYagcfeA4ctb4wIQxo=; b=RV3/59hdtuQm+yjzHye0ILL9fTwnHtoxfqgdKBGcZiV7DdrL5vkjrbWzMhj1kBCz6l Zm2nWALoU6IKH8lLYMr+FQkGybSX8WZc66CdaI7p307vxNwJO/ZRc4N9OGHT48DnePiK CVFKIHVx1UN9T0RdOgqiFKJhn4yi1jOezW+2EI3wfZJA6+eE7XGC0ynf238NICA337k8 ZmTqwl+0Lq3HlcyvEDqdr+3tET2SVd2fvu7EIJRPrqJo5IOg+VvaSsnj+xMJKYxUqRyF KVXm3x2RYpDEqnLqOad18mpAXneQ9Od1xVh8+fXyCYG7lNZlGYmAAIJKHRiLUjyBfRCN T87g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=SoXg+h68; 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=linuxfoundation.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id j19-20020a1709064b5300b0078d42f9d0cfsi11028281ejv.420.2022.10.19.02.43.43; Wed, 19 Oct 2022 02:44:20 -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=@linuxfoundation.org header.s=korg header.b=SoXg+h68; 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=linuxfoundation.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231375AbiJSJdJ (ORCPT + 99 others); Wed, 19 Oct 2022 05:33:09 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:47606 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233697AbiJSJ3H (ORCPT ); Wed, 19 Oct 2022 05:29:07 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 5B2C1EB746; Wed, 19 Oct 2022 02:12:56 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id E7455617E1; Wed, 19 Oct 2022 09:02:05 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id D87D0C433D6; Wed, 19 Oct 2022 09:02:04 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1666170125; bh=obz5FPNMsHHx1sO6B0yQTmd5pxFcPPFY4b0ZdeXu71Q=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=SoXg+h68uwHN9yxcnKp+JRJIzYU8jFuOsZtce9+xdF2dm3ANJGLVLvX3kMw13DRAm 9HIyhKmdH18pq5Wjtk3EeVlHq+ezUJJ+89B2JK9QNttFfgarkc6DM754LHcfgQfKeE 1Gj/dDHfkIhl6Je/AlYEn2hi5hlxPhA19SSeU2z0= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Olga Kornievskaia , Bernard Metzler , Leon Romanovsky , Sasha Levin Subject: [PATCH 6.0 537/862] RDMA/siw: Always consume all skbuf data in sk_data_ready() upcall. Date: Wed, 19 Oct 2022 10:30:24 +0200 Message-Id: <20221019083313.678213207@linuxfoundation.org> X-Mailer: git-send-email 2.38.0 In-Reply-To: <20221019083249.951566199@linuxfoundation.org> References: <20221019083249.951566199@linuxfoundation.org> User-Agent: quilt/0.67 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-7.4 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_HI, SPF_HELO_NONE,SPF_PASS 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 From: Bernard Metzler [ Upstream commit 754209850df8367c954ac1de7671c7430b1f342c ] For header and trailer/padding processing, siw did not consume new skb data until minimum amount present to fill current header or trailer structure, including potential payload padding. Not consuming any data during upcall may cause a receive stall, since tcp_read_sock() is not upcalling again if no new data arrive. A NFSoRDMA client got stuck at RDMA Write reception of unaligned payload, if the current skb did contain only the expected 3 padding bytes, but not the 4 bytes CRC trailer. Expecting 4 more bytes already arrived in another skb, and not consuming those 3 bytes in the current upcall left the Write incomplete, waiting for the CRC forever. Fixes: 8b6a361b8c48 ("rdma/siw: receive path") Reported-by: Olga Kornievskaia Tested-by: Olga Kornievskaia Signed-off-by: Bernard Metzler Link: https://lore.kernel.org/r/20220920081202.223629-1-bmt@zurich.ibm.com Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin --- drivers/infiniband/sw/siw/siw_qp_rx.c | 27 +++++++++++++++------------ 1 file changed, 15 insertions(+), 12 deletions(-) diff --git a/drivers/infiniband/sw/siw/siw_qp_rx.c b/drivers/infiniband/sw/siw/siw_qp_rx.c index 875ea6f1b04a..fd721cc19682 100644 --- a/drivers/infiniband/sw/siw/siw_qp_rx.c +++ b/drivers/infiniband/sw/siw/siw_qp_rx.c @@ -961,27 +961,28 @@ int siw_proc_terminate(struct siw_qp *qp) static int siw_get_trailer(struct siw_qp *qp, struct siw_rx_stream *srx) { struct sk_buff *skb = srx->skb; + int avail = min(srx->skb_new, srx->fpdu_part_rem); u8 *tbuf = (u8 *)&srx->trailer.crc - srx->pad; __wsum crc_in, crc_own = 0; siw_dbg_qp(qp, "expected %d, available %d, pad %u\n", srx->fpdu_part_rem, srx->skb_new, srx->pad); - if (srx->skb_new < srx->fpdu_part_rem) - return -EAGAIN; - - skb_copy_bits(skb, srx->skb_offset, tbuf, srx->fpdu_part_rem); + skb_copy_bits(skb, srx->skb_offset, tbuf, avail); - if (srx->mpa_crc_hd && srx->pad) - crypto_shash_update(srx->mpa_crc_hd, tbuf, srx->pad); + srx->skb_new -= avail; + srx->skb_offset += avail; + srx->skb_copied += avail; + srx->fpdu_part_rem -= avail; - srx->skb_new -= srx->fpdu_part_rem; - srx->skb_offset += srx->fpdu_part_rem; - srx->skb_copied += srx->fpdu_part_rem; + if (srx->fpdu_part_rem) + return -EAGAIN; if (!srx->mpa_crc_hd) return 0; + if (srx->pad) + crypto_shash_update(srx->mpa_crc_hd, tbuf, srx->pad); /* * CRC32 is computed, transmitted and received directly in NBO, * so there's never a reason to convert byte order. @@ -1083,10 +1084,9 @@ static int siw_get_hdr(struct siw_rx_stream *srx) * completely received. */ if (iwarp_pktinfo[opcode].hdr_len > sizeof(struct iwarp_ctrl_tagged)) { - bytes = iwarp_pktinfo[opcode].hdr_len - MIN_DDP_HDR; + int hdrlen = iwarp_pktinfo[opcode].hdr_len; - if (srx->skb_new < bytes) - return -EAGAIN; + bytes = min_t(int, hdrlen - MIN_DDP_HDR, srx->skb_new); skb_copy_bits(skb, srx->skb_offset, (char *)c_hdr + srx->fpdu_part_rcvd, bytes); @@ -1096,6 +1096,9 @@ static int siw_get_hdr(struct siw_rx_stream *srx) srx->skb_new -= bytes; srx->skb_offset += bytes; srx->skb_copied += bytes; + + if (srx->fpdu_part_rcvd < hdrlen) + return -EAGAIN; } /* -- 2.35.1