• J. Bruce Fields's avatar
    nfsd4: fix cached replies to solo SEQUENCE compounds · 085def3a
    J. Bruce Fields authored
    Currently our handling of 4.1+ requests without "cachethis" set is
    confusing and not quite correct.
    
    Suppose a client sends a compound consisting of only a single SEQUENCE
    op, and it matches the seqid in a session slot (so it's a retry), but
    the previous request with that seqid did not have "cachethis" set.
    
    The obvious thing to do might be to return NFS4ERR_RETRY_UNCACHED_REP,
    but the protocol only allows that to be returned on the op following the
    SEQUENCE, and there is no such op in this case.
    
    The protocol permits us to cache replies even if the client didn't ask
    us to.  And it's easy to do so in the case of solo SEQUENCE compounds.
    
    So, when we get a solo SEQUENCE, we can either return the previously
    cached reply or NFSERR_SEQ_FALSE_RETRY if we notice it differs in some
    way from the original call.
    
    Currently, we're returning a corrupt reply in the case a solo SEQUENCE
    matches a previous compound with more ops.  This actually matters
    because the Linux client recently started doing this as a way to recover
    from lost replies to idempotent operations in the case the process doing
    the original reply was killed: in that case it's difficult to keep the
    original arguments around to do a real retry, and the client no longer
    cares what the result is anyway, but it would like to make sure that the
    slot's sequence id has been incremented, and the solo SEQUENCE assures
    that: if the server never got the original reply, it will increment the
    sequence id.  If it did get the original reply, it won't increment, and
    nothing else that about the reply really matters much.  But we can at
    least attempt to return valid xdr!
    Tested-by: 's avatarOlga Kornievskaia <aglo@umich.edu>
    Signed-off-by: 's avatarJ. Bruce Fields <bfields@redhat.com>
    085def3a