All of
 help / color / mirror / Atom feed
From: David Howells <>
To: Tom Talpey <>
Cc:, Steve French <>,
	Shyam Prasad N <>,
	Rohith Surabattula <>,
	Long Li <>,
	Namjae Jeon <>,
	Stefan Metzmacher <>,
	Jeff Layton <>,
Subject: Re: [PATCH] cifs: Fix oops due to uncleared server->smbd_conn in reconnect
Date: Wed, 25 Jan 2023 20:41:19 +0000	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

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

However, fallocate doesn't work:

   # rdma link add siw0 type siw netdev enp6s0 # andromeda, softIWarp
   # mount // /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.


  parent reply	other threads:[~2023-01-25 20:43 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 [this message]
2023-01-25 22:24     ` Tom Talpey
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

Reply instructions:

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.