From patchwork Mon Aug 28 20:11:58 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Andrew Boyer X-Patchwork-Id: 9926099 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 6102B60329 for ; Mon, 28 Aug 2017 20:18:05 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 541F92873C for ; Mon, 28 Aug 2017 20:18:05 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 48B2928746; Mon, 28 Aug 2017 20:18:05 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.8 required=2.0 tests=BAYES_00,DKIM_SIGNED, RCVD_IN_DNSWL_HI,T_DKIM_INVALID autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id E664E2873C for ; Mon, 28 Aug 2017 20:18:04 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751237AbdH1USE (ORCPT ); Mon, 28 Aug 2017 16:18:04 -0400 Received: from esa6.dell-outbound.iphmx.com ([68.232.149.229]:63311 "EHLO esa6.dell-outbound.iphmx.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751182AbdH1USD (ORCPT ); Mon, 28 Aug 2017 16:18:03 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dell.com; i=@dell.com; q=dns/txt; s=smtpout; t=1503951483; x=1535487483; h=from:to:cc:subject:date:message-id:in-reply-to: references; bh=LP06SEN4iad52DfaMYUpJaNHP1wzth2vtQ9EB2PNMMY=; b=LaIw0FqNG0w6Iy+2VvsscicJBzueTqILmXO3LZJrZ6lNpcXpcRG9mJsO fl9nqN56voN/FI7XpviMgUzPK2A+Td2n4+pIV3qys1XLFSaTDmgNsNWTv ZI6xwh4zJYYzD2QtJXygOrEVnJ6tLdWQxApRudcx1+rFrrbHqqELciHdn E=; Received: from esa6.dell-outbound2.iphmx.com ([68.232.154.99]) by esa6.dell-outbound.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 28 Aug 2017 15:17:07 -0500 Received: from mailuogwhop.emc.com ([168.159.213.141]) by esa6.dell-outbound2.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 29 Aug 2017 02:17:07 +0600 Received: from maildlpprd03.lss.emc.com (maildlpprd03.lss.emc.com [10.253.24.35]) by mailuogwprd04.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id v7SKH4no025261 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 28 Aug 2017 16:17:05 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd04.lss.emc.com v7SKH4no025261 Received: from mailsyshubprd52.lss.emc.com (mailsyshubprd52.lss.emc.com [10.106.48.27]) by maildlpprd03.lss.emc.com (RSA Interceptor); Mon, 28 Aug 2017 16:16:07 -0400 Received: from hopcyc-boyera-1.corp.emc.com (hopcyc-boyera-1.cec.lab.emc.com [10.244.91.191]) by mailsyshubprd52.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id v7SKC7PI014260; Mon, 28 Aug 2017 16:16:52 -0400 From: Andrew Boyer To: monis@mellanox.com, yonatanc@mellanox.com, linux-rdma@vger.kernel.org Cc: Andrew Boyer Subject: [PATCH v2 10/11] IB/rxe: Avoid ICRC errors by copying into the skb first Date: Mon, 28 Aug 2017 16:11:58 -0400 Message-Id: <1503951119-25573-11-git-send-email-andrew.boyer@dell.com> X-Mailer: git-send-email 1.8.3.1 In-Reply-To: <1503951119-25573-1-git-send-email-andrew.boyer@dell.com> References: <1503687956-7110-1-git-send-email-andrew.boyer@dell.com> <1503951119-25573-1-git-send-email-andrew.boyer@dell.com> X-RSA-Classifications: public X-Sentrion-Hostname: mailuogwprd04.lss.emc.com Sender: linux-rdma-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-rdma@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP The current process is to first calculate the CRC and then copy the client data into the packet. This leaves a window in which the packet contents and CRC can get out of sync, if the client changes the data after the CRC is calculated but before the data is copied. By copying the data into the packet and then calculating the CRC directly from the packet contents we eliminate the window. This can be seen with qperf's ud_bi_bw test. This seems like very strange/reckless client behavior, but whether the client has mangled its data or not RXE should be able to transfer it reliably. Fixes: 8700e3e7c485 ("Soft RoCE driver") Signed-off-by: Andrew Boyer --- drivers/infiniband/sw/rxe/rxe_mr.c | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/drivers/infiniband/sw/rxe/rxe_mr.c b/drivers/infiniband/sw/rxe/rxe_mr.c index e37cc89..5c2684b 100644 --- a/drivers/infiniband/sw/rxe/rxe_mr.c +++ b/drivers/infiniband/sw/rxe/rxe_mr.c @@ -367,11 +367,11 @@ int rxe_mem_copy(struct rxe_mem *mem, u64 iova, void *addr, int length, dest = (dir == to_mem_obj) ? ((void *)(uintptr_t)iova) : addr; + memcpy(dest, src, length); + if (crcp) *crcp = rxe_crc32(to_rdev(mem->pd->ibpd.device), - *crcp, src, length); - - memcpy(dest, src, length); + *crcp, dest, length); return 0; } @@ -401,11 +401,11 @@ int rxe_mem_copy(struct rxe_mem *mem, u64 iova, void *addr, int length, if (bytes > length) bytes = length; + memcpy(dest, src, bytes); + if (crcp) crc = rxe_crc32(to_rdev(mem->pd->ibpd.device), - crc, src, bytes); - - memcpy(dest, src, bytes); + crc, dest, bytes); length -= bytes; addr += bytes;