• Chuck Lever's avatar
    xprtrdma: Invalidate in the RPC reply handler · 68791649
    Chuck Lever authored
    There is a window between the time the RPC reply handler wakes the
    waiting RPC task and when xprt_release() invokes ops->buf_free.
    During this time, memory regions containing the data payload may
    still be accessed by a broken or malicious server, but the RPC
    application has already been allowed access to the memory containing
    the RPC request's data payloads.
    
    The server should be fenced from client memory containing RPC data
    payloads _before_ the RPC application is allowed to continue.
    
    This change also more strongly enforces send queue accounting. There
    is a maximum number of RPC calls allowed to be outstanding. When an
    RPC/RDMA transport is set up, just enough send queue resources are
    allocated to handle registration, Send, and invalidation WRs for
    each those RPCs at the same time.
    
    Before, additional RPC calls could be dispatched while invalidation
    WRs were still consuming send WQEs. When invalidation WRs backed
    up, dispatching additional RPCs resulted in a send queue overrun.
    
    Now, the reply handler prevents RPC dispatch until invalidation is
    complete. This prevents RPC call dispatch until there are enough
    send queue resources to proceed.
    
    Still to do: If an RPC exits early (say, ^C), the reply handler has
    no opportunity to perform invalidation. Currently, xprt_rdma_free()
    still frees remaining RDMA resources, which could deadlock.
    Additional changes are needed to handle invalidation properly in this
    case.
    Reported-by: default avatarJason Gunthorpe <jgunthorpe@obsidianresearch.com>
    Signed-off-by: default avatarChuck Lever <chuck.lever@oracle.com>
    Tested-by: default avatarDevesh Sharma <devesh.sharma@avagotech.com>
    Signed-off-by: default avatarAnna Schumaker <Anna.Schumaker@Netapp.com>
    68791649
rpc_rdma.c 28.9 KB