• Chuck Lever's avatar
    svcrdma: Handle additional inline content · a97c331f
    Chuck Lever authored
    Most NFS RPCs place their large payload argument at the end of the
    RPC header (eg, NFSv3 WRITE). For NFSv3 WRITE and SYMLINK, RPC/RDMA
    sends the complete RPC header inline, and the payload argument in
    the read list. Data in the read list is the last part of the XDR
    stream.
    
    One important case is not like this, however. NFSv4 COMPOUND is a
    counted array of operations. A WRITE operation, with its large data
    payload, can appear in the middle of the compound's operations
    array. Thus NFSv4 WRITE compounds can have header content after the
    WRITE payload.
    
    The Linux client, for example, performs an NFSv4 WRITE like this:
    
      { PUTFH, WRITE, GETATTR }
    
    Though RFC 5667 is not precise about this, the proper way to convey
    this compound is to place the GETATTR inline, _after_ the front of
    the RPC header. The receiver inserts the read list payload into the
    XDR stream after the initial WRITE arguments, and before the GETATTR
    operation, thanks to the value of the read list "position" field.
    
    The Linux client currently sends the GETATTR at the end of the
    RPC/RDMA read list, which is incorrect. It will be corrected in the
    future.
    
    The Linux server currently rejects NFSv4 compounds with inline
    content after the read list. For the above NFSv4 WRITE compound, the
    NFS compound header indicates there are three operations, but the
    server finds nonsense when it looks in the XDR stream for the third
    operation, and the compound fails with OP_ILLEGAL.
    
    Move trailing inline content to the end of the XDR buffer's page
    list. This presents incoming NFSv4 WRITE compounds to NFSD in the
    same way the socket transport does.
    Signed-off-by: default avatarChuck Lever <chuck.lever@oracle.com>
    Reviewed-by: default avatarSteve Wise <swise@opengridcomputing.com>
    Signed-off-by: default avatarJ. Bruce Fields <bfields@redhat.com>
    a97c331f
svc_rdma_recvfrom.c 19.2 KB