From patchwork Tue Nov 15 22:44:02 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: David Howells X-Patchwork-Id: 20622 Return-Path: Delivered-To: ouuuleilei@gmail.com Received: by 2002:a5d:6687:0:0:0:0:0 with SMTP id l7csp2977581wru; Tue, 15 Nov 2022 14:47:34 -0800 (PST) X-Google-Smtp-Source: AA0mqf7A8H2+GllYRuum04juV8myxAK9aFhQtwnIbjkbY0aahSRAV5tL6+Zy/do5ntlCVQWU4xPQ X-Received: by 2002:a17:907:76d2:b0:78d:8c6b:397b with SMTP id kf18-20020a17090776d200b0078d8c6b397bmr15104797ejc.364.1668552454673; Tue, 15 Nov 2022 14:47:34 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1668552454; cv=none; d=google.com; s=arc-20160816; b=bp67+8ocJ1b4dB+pDMdkZbygwdYUBhdl6Bs0Vs+WW4FOb+n/P9IPqxZ63XpbZqT7Ks kn5j25uUYR8o8GKf1cHiERtMoIAiDhJJ9arktBuJmv/h7OoKvIgLjgPzXlDaclWAAL+Z irESQ8Q2zw4GU6YaPPDCpZ4hAlvZMJvXNUSBdv1yDfG0dUF/kU4L7Gz80VHRbzvZHZRn cfF0Bcu0hKQdFrijD2IfWCznUvg3QkD/Lg7xxTDjY1BQe3n2Z2KN8Tzx2F5r/BcAV70q sbnXpV5jXX3b6GNWnpLUYeEg/N7P+mzvgUCzW073l5R5HxBgcvld/+28NLenMmH1Xa/I ol/g== 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:message-id:date:cc:to:from:subject:organization :dkim-signature; bh=Sr5cmUXaaquPODOsp7wOywLMH70ji6BY41qEcJlkct8=; b=KuPSy1jxbzJ8TsuH1/BwAabQhpOI+stA4gbgVAmQPfxVgp5ebjOqpsKEXqQE9FYE2s txHg09h6uFDDyVJ0Y+8mZ1r9LKoHZG5Vyouzfm2L8Ys11S7IjQn87AkBzyKfo8Ff7t+n z+QBR6WhjhWgdk/B4JnvMWJ2EuHnewNUQl9otd9giVDgSjUUvybg2QqRnagFkxoS8S6E lWIUPwq2+dmTV+xMwJkWDHumtvH+Dr6ZMnklcz0uqymbq+3TjPWNgOw4o46Kl5wjxCFw fSht/dz+mikOjR60l1/9aRUg/4H4fPXWwnDsrAHcL7OfqGsxYEWhUkyxZDU7WF4XRYBU Et5Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=F33jFi2U; 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=redhat.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id l12-20020a170906644c00b00767e24156dbsi8302933ejn.256.2022.11.15.14.47.11; Tue, 15 Nov 2022 14:47:34 -0800 (PST) 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=@redhat.com header.s=mimecast20190719 header.b=F33jFi2U; 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=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231871AbiKOWpO (ORCPT + 99 others); Tue, 15 Nov 2022 17:45:14 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42076 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231319AbiKOWpD (ORCPT ); Tue, 15 Nov 2022 17:45:03 -0500 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 3CFE21CFDD for ; Tue, 15 Nov 2022 14:44:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1668552251; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=Sr5cmUXaaquPODOsp7wOywLMH70ji6BY41qEcJlkct8=; b=F33jFi2UtY0+l0Zn23UUyBV8awHtqDldtvgQ7TZ8PGgUrk4oQIVtDT+37sNA/OMlrWbMN9 0QCcPpPcLyF/dXHpB6wWRCWtQ50lYwg+oQUGC3RB4VCY+Vwg8ovUGL900zSUFXxfELSF5N HB+ge0ji6lWiLapTFR2rTdXaOD5jK9c= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-383-qYs-SrBBO5qTlAyD7FTboQ-1; Tue, 15 Nov 2022 17:44:06 -0500 X-MC-Unique: qYs-SrBBO5qTlAyD7FTboQ-1 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.rdu2.redhat.com [10.11.54.2]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 47DD9800B23; Tue, 15 Nov 2022 22:44:06 +0000 (UTC) Received: from warthog.procyon.org.uk (unknown [10.33.36.24]) by smtp.corp.redhat.com (Postfix) with ESMTP id 40F4B40C6EC3; Tue, 15 Nov 2022 22:44:05 +0000 (UTC) Organization: Red Hat UK Ltd. Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SI4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 3798903 Subject: [PATCH] cifs: Fix problem with encrypted RDMA data read From: David Howells To: smfrench@gmail.com, tom@talpey.com Cc: Long Li , Namjae Jeon , Stefan Metzmacher , linux-cifs@vger.kernel.org, dhowells@redhat.com, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org Date: Tue, 15 Nov 2022 22:44:02 +0000 Message-ID: <166855224228.1998592.2212551359609792175.stgit@warthog.procyon.org.uk> User-Agent: StGit/1.5 MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.1 on 10.11.54.2 X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_NONE autolearn=unavailable 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 X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1749604059053394872?= X-GMAIL-MSGID: =?utf-8?q?1749604059053394872?= When the cifs client is talking to the ksmbd server by RDMA and the ksmbd server has "smb3 encryption = yes" in its config file, the normal PDU stream is encrypted, but the directly-delivered data isn't in the stream (and isn't encrypted), but is rather delivered by DDP/RDMA packets (at least with IWarp). Currently, the direct delivery fails with: buf can not contain only a part of read data WARNING: CPU: 0 PID: 4619 at fs/cifs/smb2ops.c:4731 handle_read_data+0x393/0x405 ... RIP: 0010:handle_read_data+0x393/0x405 ... smb3_handle_read_data+0x30/0x37 receive_encrypted_standard+0x141/0x224 cifs_demultiplex_thread+0x21a/0x63b kthread+0xe7/0xef ret_from_fork+0x22/0x30 The problem apparently stemming from the fact that it's trying to manage the decryption, but the data isn't in the smallbuf, the bigbuf or the page array). This can be fixed simply by inserting an extra case into handle_read_data() that checks to see if use_rdma_mr is true, and if it is, just setting rdata->got_bytes to the length of data delivered and allowing normal continuation. This can be seen in an IWarp packet trace. With the upstream code, it does a DDP/RDMA packet, which produces the warning above and then retries, retrieving the data inline, spread across several SMBDirect messages that get glued together into a single PDU. With the patch applied, only the DDP/RDMA packet is seen. Note that this doesn't happen if the server isn't told to encrypt stuff and it does also happen with softRoCE. Signed-off-by: David Howells cc: Steve French cc: Tom Talpey cc: Long Li cc: Namjae Jeon cc: Stefan Metzmacher cc: linux-cifs@vger.kernel.org --- fs/cifs/smb2ops.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/fs/cifs/smb2ops.c b/fs/cifs/smb2ops.c index 880cd494afea..8d459f60f27b 100644 --- a/fs/cifs/smb2ops.c +++ b/fs/cifs/smb2ops.c @@ -4726,6 +4726,9 @@ handle_read_data(struct TCP_Server_Info *server, struct mid_q_entry *mid, iov.iov_base = buf + data_offset; iov.iov_len = data_len; iov_iter_kvec(&iter, WRITE, &iov, 1, data_len); + } else if (use_rdma_mr) { + /* The data was delivered directly by RDMA. */ + rdata->got_bytes = data_len; } else { /* read response payload cannot be in both buf and pages */ WARN_ONCE(1, "buf can not contain only a part of read data");