Message ID | 167391070712.2311931.8909671251130425914.stgit@warthog.procyon.org.uk |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:adf:eb09:0:0:0:0:0 with SMTP id s9csp1458067wrn; Mon, 16 Jan 2023 15:44:05 -0800 (PST) X-Google-Smtp-Source: AMrXdXuiew4asM3LrY4COrWfQDtXR2m151OJUI1i+POgNaq8Udp9Ghjpj8UptHHNO+8fkItdFDLz X-Received: by 2002:a17:902:b705:b0:193:3989:b62 with SMTP id d5-20020a170902b70500b0019339890b62mr1229118pls.67.1673912644802; Mon, 16 Jan 2023 15:44:04 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1673912644; cv=none; d=google.com; s=arc-20160816; b=tJ948wj00OsDNvQT9jEXJ6xz4ZxZHvhGuKCbDkKFq1E05+IGtNbnAvdlwqJxW/bANv mJuO5c4jdTazYuZbhVFAgwY8up6+RZQMO6qgA22OdBcSmjGodq9Y4QdeHEcnL0pvAAij F2hGI3tuKm1zds24w88UPbLBwYLe8yz6SJbtIR9IR/zl8qlXDmX2IqL9mnB4FOmEm5+F mxIsktPVA4L6+AZqHMAc2n9dvtghLd84Mr9R8nw5GKE9qCYhqijSYUEIX/AvzAyCF7ZG LnS3n1z8iS/ACw++JaGDN3wBN3glwKYeZyjNJUhTKaua//WXhQ1QbjP/15Pge3nGHLwA +g8A== 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:cc:to:from :subject:organization:dkim-signature; bh=Nw4FQbdWbVj4MBsaopY4M6MScTLsVpfgXMad66KYZwU=; b=V/xhyV1gLizlJ+u9Komo2VbMgVK1WLWG8BSL+ismtqIKsHHlu64H86WxnObnnoKuGb 3/I84JA3l6atcG0ISeEy3anOhvCcB+pKE5TrzFaxENpVXM+t56RYJzI1jHj86TzStOog 4n8tp26pWIw3bo3hY6q/NudtNL86e+thnLRvfzweYWI6xrk1RLGD6y9HnqGO0qhrDy2n hgL4Wa59cwjyxv0ge+oEVCggInWlduv3JwYkAiBWwbkOkVDaatHCi4+c6RxNDZvj7eIe C+Dqsd7F4uSmdwfN64t91O8paW8h/Kw6gcJWfO9GjRMC3iqgZtxE2hC7greNSCsCAwqv Kl/g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=RjpdJDD3; 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 b12-20020a170902d50c00b00192721d6a97si2573304plg.499.2023.01.16.15.43.48; Mon, 16 Jan 2023 15:44:04 -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=RjpdJDD3; 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 S235109AbjAPXU3 (ORCPT <rfc822;stefanalexe802@gmail.com> + 99 others); Mon, 16 Jan 2023 18:20:29 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:55928 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235776AbjAPXTg (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Mon, 16 Jan 2023 18:19:36 -0500 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 7D6663253D for <linux-kernel@vger.kernel.org>; Mon, 16 Jan 2023 15:12:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1673910713; 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: in-reply-to:in-reply-to:references:references; bh=Nw4FQbdWbVj4MBsaopY4M6MScTLsVpfgXMad66KYZwU=; b=RjpdJDD3sLbe7gnvYV1G4r09VyO3HtvoRyFwJftJlu/7dYHqrHegEX9QrbeHEp/7Y5JrHL yH1Mzt6gLeiPH9rsTiyqKGiHFE+yJC/RXpuxXTjDPCMGAtU6CLdcUFusq1YHwYQSp6Pc0p srP+nU6Ap7+DvxNqKNhm8EpnzSWMq8Y= Received: from mimecast-mx02.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-14-yziFx7y5NACL1vK30mvFNA-1; Mon, 16 Jan 2023 18:11:50 -0500 X-MC-Unique: yziFx7y5NACL1vK30mvFNA-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 7BA33380390A; Mon, 16 Jan 2023 23:11:49 +0000 (UTC) Received: from warthog.procyon.org.uk (unknown [10.33.36.23]) by smtp.corp.redhat.com (Postfix) with ESMTP id AEA5240C6EC4; Mon, 16 Jan 2023 23:11:47 +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 v6 31/34] cifs: Fix problem with encrypted RDMA data read From: David Howells <dhowells@redhat.com> To: Al Viro <viro@zeniv.linux.org.uk> Cc: Steve French <smfrench@gmail.com>, Tom Talpey <tom@talpey.com>, Long Li <longli@microsoft.com>, Namjae Jeon <linkinjeon@kernel.org>, Stefan Metzmacher <metze@samba.org>, linux-cifs@vger.kernel.org, dhowells@redhat.com, Christoph Hellwig <hch@infradead.org>, Matthew Wilcox <willy@infradead.org>, Jens Axboe <axboe@kernel.dk>, Jan Kara <jack@suse.cz>, Jeff Layton <jlayton@kernel.org>, Logan Gunthorpe <logang@deltatee.com>, linux-fsdevel@vger.kernel.org, linux-block@vger.kernel.org, linux-kernel@vger.kernel.org Date: Mon, 16 Jan 2023 23:11:47 +0000 Message-ID: <167391070712.2311931.8909671251130425914.stgit@warthog.procyon.org.uk> In-Reply-To: <167391047703.2311931.8115712773222260073.stgit@warthog.procyon.org.uk> References: <167391047703.2311931.8115712773222260073.stgit@warthog.procyon.org.uk> User-Agent: StGit/1.5 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit 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: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1755224625718782128?= X-GMAIL-MSGID: =?utf-8?q?1755224625718782128?= |
Series |
iov_iter: Improve page extraction (ref, pin or just list)
|
|
Commit Message
David Howells
Jan. 16, 2023, 11:11 p.m. UTC
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 <dhowells@redhat.com>
cc: Steve French <smfrench@gmail.com>
cc: Tom Talpey <tom@talpey.com>
cc: Long Li <longli@microsoft.com>
cc: Namjae Jeon <linkinjeon@kernel.org>
cc: Stefan Metzmacher <metze@samba.org>
cc: linux-cifs@vger.kernel.org
Link: https://lore.kernel.org/r/166855224228.1998592.2212551359609792175.stgit@warthog.procyon.org.uk/ # v1
---
fs/cifs/smb2ops.c | 3 +++
1 file changed, 3 insertions(+)
Comments
Am 17.01.23 um 00:11 schrieb David Howells: > 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). In that case the client must not use DDP/RDMA offload! This needs to be fixed in the request code for both read and write! metze
diff --git a/fs/cifs/smb2ops.c b/fs/cifs/smb2ops.c index 387effcb905d..fabb1e135faa 100644 --- a/fs/cifs/smb2ops.c +++ b/fs/cifs/smb2ops.c @@ -4720,6 +4720,9 @@ handle_read_data(struct TCP_Server_Info *server, struct mid_q_entry *mid, if (length < 0) return length; rdata->got_bytes = 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");