Re: [UNVERIFIED SENDER] Re: [PATCH 1/1] NFSv4.2: fix LISTXATTR buffer receive size

From: Frank van der Linden <fllinden@amazon.com>
To: Olga Kornievskaia <olga.kornievskaia@gmail.com>
Cc: Chuck Lever <chuck.lever@oracle.com>,
	Trond Myklebust <trond.myklebust@hammerspace.com>,
	Anna Schumaker <anna.schumaker@netapp.com>,
	Linux NFS Mailing List <linux-nfs@vger.kernel.org>
Subject: Re: [UNVERIFIED SENDER] Re: [PATCH 1/1] NFSv4.2: fix LISTXATTR buffer receive size
Date: Mon, 23 Nov 2020 19:24:34 +0000	[thread overview]
Message-ID: <20201123192434.GB28906@dev-dsk-fllinden-2c-c1893d73.us-west-2.amazon.com> (raw)
In-Reply-To: <20201123173802.GA26158@dev-dsk-fllinden-2c-c1893d73.us-west-2.amazon.com>

On Mon, Nov 23, 2020 at 05:38:02PM +0000, Frank van der Linden wrote:
> It wouldn't be the end of the world to change LISTXATTRS (and GETXATTR)
> to use preallocated pages. But, I didn't do that because I didn't want to
> waste the max size (64k) every time, even though you usually just get
> a few hundred bytes at most. So it seems like fixing XDRBUF_SPARSE_PAGES
> is cleaner.

Correcting myself here.. this is true of GETXATTR, since there is no
maximum length argument for that call - so your only choice is to
allocate the max of what you can handle, and SPARSE seems to
be the best option fr that.

For LISTXATTRS, there is a max length argument. It's a bit unusual,
in that it specifies the maximum number of bytes of *XDR* data you
want to receive. So you don't need to allocate the maximum number
of pages.  But, I decided to still use the SPARSE option, since the
common 0 length argument to the listxattr syscall, used to probe
the length of the buffer needed, would still require the maximum
length (64k) to be allocated, because there is no 0 lengh 'probe'
option for the RPC. So all you can do is ask for the maximum
size you can handle, and see what you get back to determine
the length.

Olga's comment about caching: the code actually does cache
the data for all valid replies, even if the system call
only was a len == 0 probe call. That way, the followup
system call that actually retrieves the data can normally
just get it from the cache.

In any case, I need to set up an RDMA environment to see
if I can reproduce and fix the issue. I hope to do that
today or tomorrow.

- Frank