From: Tom Talpey <firstname.lastname@example.org>
To: David Howells <email@example.com>
Cc: Steve French <firstname.lastname@example.org>,
Shyam Prasad N <email@example.com>,
Rohith Surabattula <firstname.lastname@example.org>,
Long Li <email@example.com>,
Namjae Jeon <firstname.lastname@example.org>,
Stefan Metzmacher <email@example.com>,
Jeff Layton <firstname.lastname@example.org>,
Subject: Re: [PATCH] cifs: Fix oops due to uncleared server->smbd_conn in reconnect
Date: Wed, 25 Jan 2023 17:24:16 -0500 [thread overview]
Message-ID: <email@example.com> (raw)
On 1/25/2023 3:41 PM, David Howells wrote:
> Hi Tom,
> Steve suggested I should ask you about this.
> I have IWarp RDMA mostly working with my iteratorisation patches - certainly
> better than without them, but I think that's mostly due to the patch that
> Stefan Metzmacher so dislikes ("cifs: Fix problem with encrypted RDMA data
The encryption problem is real, and Metze is correct. The client
shouldnt be requesting, and the server shouldn't be responding,
with unencrypted messages on encrypted shares.
The problem is, the proper fix is complicated.
- We've reported the issue to Microsoft, but they have not yet
said how the Windows client and server are intended to behave,
and they have not yet revealed how the protocol document will
be changed. At this time, the Linux implementation conforms,
dangerously, with the published spec.
- There is some unexplained behavior in the client when the
connection is lost after failing to decrypt the unencrypted
response. In my earlier look at the traces, for some reason
it reconnects and retries without requesting RDMA. This
succeeds, because the "inline" requests and responses are
encrypted and decrypted successfully.
It's interesting that this occurs on a compounded fallocate call.
That might be a clue, too.
What are you trying to test? Since encrypted SMBDirect traffic
is known to have an issue, I guess I'd suggest turning off
encryption-by-default on the share.
I'll poke Microsoft again on the protocol ticket.
> However, fallocate doesn't work:
> # rdma link add siw0 type siw netdev enp6s0 # andromeda, softIWarp
> # mount //192.168.6.1/test /xfstest.test -o user=shares,pass=foobar,rdma
> # fallocate -l 1M /xfstest.test/hello
> fallocate: fallocate failed: Resource temporarily unavailable
> Because smb3_simple_fallocate_write_range() calls SMB2_write(), which calls
> cifs_send_recv() then compound_send_recv() and thence to smb_send_rqst().
> smb_send_rqst() encrypts the buffer it is given and smbd_send() attempts to
> shovel it to the server using Direct Data Placement - which I think might fail
> because the data is encrypted.
> In one run of the above commands, the data in the kvec array looked like:
> before the smb_send_rqst() gets to ->init_transform_rq() and like:
> after. The encrypted data is seen on the wire in DDP/RDMA packets.
> Any thoughts as to how to fix this?
> Does it need to pass a flag down to suppress the encryption or suppress the
> use of direct data placement? Or should it perhaps go through something like
> Note also that it encrypts the buffer in place and then
> smb3_simple_fallocate_write_range() reuses the buffer multiple times without
> clearing it.
> I've pushed my cifs iteratorisation patches to:
> I can post them by email a bit later.
next prev parent reply other threads:[~2023-01-25 22:24 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-01-24 17:48 cifs-rdma: KASAN-detected UAF when using rxe driver David Howells
2023-01-25 7:48 ` David Howells
2023-01-25 14:02 ` [PATCH] cifs: Fix oops due to uncleared server->smbd_conn in reconnect David Howells
2023-01-25 14:47 ` Tom Talpey
2023-01-25 15:52 ` Tom Talpey
2023-01-25 16:20 ` Steve French
2023-01-25 20:41 ` David Howells
2023-01-25 22:24 ` Tom Talpey [this message]
2023-01-25 22:43 ` David Howells
2023-01-25 22:56 ` Tom Talpey
2023-01-25 23:42 ` Namjae Jeon
2023-01-26 14:42 ` pcap of misbehaving fallocate over cifs rdma David Howells
2023-01-26 19:54 ` David Howells
2023-01-26 20:29 ` Tom Talpey
2023-01-26 20:47 ` David Howells
2023-01-26 15:20 ` [PATCH] cifs: Fix oops due to uncleared server->smbd_conn in reconnect David Howells
2023-01-26 19:22 ` Tom Talpey
2023-01-26 19:49 ` David Howells
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.