All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Howells <dhowells@redhat.com>
To: Tom Talpey <tom@talpey.com>
Cc: dhowells@redhat.com, Steve French <sfrench@samba.org>,
	Shyam Prasad N <nspmangalore@gmail.com>,
	Rohith Surabattula <rohiths.msft@gmail.com>,
	Long Li <longli@microsoft.com>,
	Namjae Jeon <linkinjeon@kernel.org>,
	Stefan Metzmacher <metze@samba.org>,
	Jeff Layton <jlayton@kernel.org>,
	linux-cifs@vger.kernel.org
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: <2302242.1674679279@warthog.procyon.org.uk> (raw)
In-Reply-To: <fa35788a-c858-11c5-5d9a-1d5c837020b6@talpey.com>

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
read").

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:

fe534d42400001000000000009000a0000000000000000001600000000000000a01300000200
0000000000000000000000000000000000000000000000000000000000000000000000000000

before the smb_send_rqst() gets to ->init_transform_rq() and like:

98eddc1bc31da7c55c00341e4dc769fa4c8b2b0ecdacbad33eb31855ec162fa2458b8437edc7
88ee0a033c84aa857b65ab31ce553594d412719cc3daf925e873e80062ec16b97c855721a42d

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
->write_iter()?

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:

	https://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git/log/?h=iov-cifs

I can post them by email a bit later.

David


  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:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=2302242.1674679279@warthog.procyon.org.uk \
    --to=dhowells@redhat.com \
    --cc=jlayton@kernel.org \
    --cc=linkinjeon@kernel.org \
    --cc=linux-cifs@vger.kernel.org \
    --cc=longli@microsoft.com \
    --cc=metze@samba.org \
    --cc=nspmangalore@gmail.com \
    --cc=rohiths.msft@gmail.com \
    --cc=sfrench@samba.org \
    --cc=tom@talpey.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* 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.