diff options
author | Chuck Lever <chuck.lever@oracle.com> | 2016-03-01 21:05:45 +0300 |
---|---|---|
committer | J. Bruce Fields <bfields@redhat.com> | 2016-03-02 00:06:33 +0300 |
commit | cf570a93748ab95cf5d13d3d8058875f970f3a66 (patch) | |
tree | f09a635ec4029682dae09c8593e770065cde2636 /include/linux/cma.h | |
parent | 08ae4e7fedc6a853ad69d6d8abb760b55988608a (diff) | |
download | linux-cf570a93748ab95cf5d13d3d8058875f970f3a66.tar.xz |
svcrdma: Do not write xdr_buf::tail in a Write chunk
When the Linux NFS server writes an odd-length data item into a
Write chunk, it finishes with XDR pad bytes. If the data item is
smaller than the Write chunk, the pad bytes are written at the end
of the data item, but still inside the chunk (ie, in the
application's buffer). Since this is direct data placement, that
exposes the pad bytes.
XDR pad bytes are inserted in order to preserve the XDR alignment
of the next XDR data item in an XDR stream. But Write chunks do not
appear in the payload XDR stream, and only one data item is allowed
in each chunk. Thus XDR padding is not needed in a Write chunk.
With NFSv4, the Linux NFS server places the results of any
operations that follow an NFSv4 READ or READLINK in the xdr_buf's
tail. Those results also should never be sent as a part of a Write
chunk. The current logic in send_write_chunks() appears to assume
that the xdr_buf's tail contains only pad bytes (ie, NFSv3).
The server should write only the contents of the xdr_buf's page list
in a Write chunk. If there's more than an XDR pad in the tail, that
needs to go inline or in the Reply chunk.
BugLink: https://bugzilla.linux-nfs.org/show_bug.cgi?id=294
Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
Signed-off-by: J. Bruce Fields <bfields@redhat.com>
Diffstat (limited to 'include/linux/cma.h')
0 files changed, 0 insertions, 0 deletions