summaryrefslogtreecommitdiff
path: root/include/linux/dell-led.h
diff options
context:
space:
mode:
authorChuck Lever <chuck.lever@oracle.com>2016-03-01 21:05:45 +0300
committerJ. Bruce Fields <bfields@redhat.com>2016-03-02 00:06:33 +0300
commitcf570a93748ab95cf5d13d3d8058875f970f3a66 (patch)
treef09a635ec4029682dae09c8593e770065cde2636 /include/linux/dell-led.h
parent08ae4e7fedc6a853ad69d6d8abb760b55988608a (diff)
downloadlinux-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/dell-led.h')
0 files changed, 0 insertions, 0 deletions