• Chuck Lever's avatar
    svcrdma: Fix send_reply() scatter/gather set-up · 0f9ae878
    Chuck Lever authored
    commit 9d11b51c upstream.
    
    The Linux NFS server returns garbage in the data payload of inline
    NFS/RDMA READ replies. These are READs of under 1000 bytes or so
    where the client has not provided either a reply chunk or a write
    list.
    
    The NFS server delivers the data payload for an NFS READ reply to
    the transport in an xdr_buf page list. If the NFS client did not
    provide a reply chunk or a write list, send_reply() is supposed to
    set up a separate sge for the page containing the READ data, and
    another sge for XDR padding if needed, then post all of the sges via
    a single SEND Work Request.
    
    The problem is send_reply() does not advance through the xdr_buf
    when setting up scatter/gather entries for SEND WR. It always calls
    dma_map_xdr with xdr_off set to zero. When there's more than one
    sge, dma_map_xdr() sets up the SEND sge's so they all point to the
    xdr_buf's head.
    
    The current Linux NFS/RDMA client always provides a reply chunk or
    a write list when performing an NFS READ over RDMA. Therefore, it
    does not exercise this particular case. The Linux server has never
    had to use more than one extra sge for building RPC/RDMA replies
    with a Linux client.
    
    However, an NFS/RDMA client _is_ allowed to send small NFS READs
    without setting up a write list or reply chunk. The NFS READ reply
    fits entirely within the inline reply buffer in this case. This is
    perhaps a more efficient way of performing NFS READs that the Linux
    NFS/RDMA client may some day adopt.
    
    Fixes: b432e6b3 ('svcrdma: Change DMA mapping logic to . . .')
    BugLink: https://bugzilla.linux-nfs.org/show_bug.cgi?id=285Signed-off-by: default avatarChuck Lever <chuck.lever@oracle.com>
    Signed-off-by: default avatarJ. Bruce Fields <bfields@redhat.com>
    [lizf: Backported to 3.4: adjust context]
    Signed-off-by: default avatarZefan Li <lizefan@huawei.com>
    0f9ae878
svc_rdma_sendto.c 20.9 KB